1 2 3 Previous Next

Product Blog

63 Posts authored by: aLTeReGo Employee

SolarWinds has a long history of being easy to try and easy to buy. Those of you who own two or more Orion Platform product modules may have realized, usually when planning your next upgrade, it's not necessarily easy to know which product module versions are compatible with others. While figuring this out may not be too terribly difficult when you own only two Orion product modules, the complexity rises significantly with each additional product module you purchase thereafter. Imagine you need to figure out which versions of your other 13 Orion Platform product and integration modules are compatible with Server & Application Monitor 6.7? Suddenly, what was previously a rather trivial task has become a daunting, and sometimes overwhelming, challenge.

 

For that reason and many more, we have some significant changes coming your way to end the madness. First though, here’s a brief history of where we've been, how we got here, and where the future will take us.

 

 

 

The Matrix

 

For many years, we attempted to make the process of deciphering compatibility between Orion Platform product modules easier through a compatibility matrix maintained within our documentation. The matrix itself was a fairly complex Excel spreadsheet that oftentimes felt like you needed a secret decoder ring to help interpret the results. For what you might imagine should be a relatively simple task, the compatibility matrix was anything but.

 

 

Upgrade Advisor

 

As the number of available Orion Platform product modules increased, we eventually realized the Compatibility Matrix had become too complex for customers to interpret, and too unwieldy for us to maintain. Thus came our next valiant attempt at improving the situation for determining multi-product compatibility, the Upgrade Advisor. The Upgrade Advisor represented a monumental leap forward compared to the Compatibility Matrix. In fact, many still rely upon it today.

 

 

 

The process is relatively straightforward. Enter in the Orion Platform product modules you currently have installed and their respective version numbers. Next, enter the version number of the product module to which you'd like to upgrade. The Upgrade Advisor will then map out the rest of the product module version numbers compatible with the newer version.

 

While fraught with good intentions, the Upgrade Advisor still suffered from the same fundamental flaw which led to the demise of the Compatibility Matrix. It still required users to be both aware of its existence and proactive about their upgrade planning. When the recommendations outlined in the Compatibility Matrix or Upgrade Advisor weren't followed, bizarre and unexplainable issues would occur due to incompatible module behavior.

 

 

Next Generation Installer

 

The latest attempt at unraveling this quagmire has been to place the information available in the Upgrade Advisor into the installer itself. Anytime before or at the time of upgrade, simply running the installer provides a list of all Orion Platform product modules currently installed and their respective versions. Next to it is the list of versions for other product modules compatible with the module version downloaded.

 

Image result for solarwinds installer upgrade

 

This method is vastly superior to both the Compatibility Matrix and Upgrade Advisor, as it requires no prior knowledge of the existence of either, nor does it require any manual steps to determine module compatibility. The installer simply handles it all for you. No muss, no fuss.

 

While the next-generation installer took all the complexity out of the equation, it introduced a fair amount of confusion. For the planners among you, it seemed counterintuitive to run an installer, days, weeks, or even months ahead of a scheduled upgrade to determine the upgrade path. For others, executing the installer on a production environment prior to the scheduled change window sounded like a dangerous proposition, assuming the mere fact of running the installer might start the upgrade process or shut down Orion services without consent or confirmation. As a result, some still found greater comfort utilizing the Upgrade Advisor this new installer was intent on replacing.

 

Does this really need to be so complicated?

 

A lot of time, effort, and different technologies have been used throughout the years in what seems to have been a vain attempt to reduce confusion and make it easier for users to identify compatibility between different product module versions. The problem, however, was never how we attempted to address the issue (though admittedly, some methods worked better than others). The ultimate solution is to change how we think about the problem in the first place: the version number itself.

 

 

Ushering in a new tomorrow

 

It's rather arbitrary that 6.9 is the Server & Application Monitor (SAM) version compatible with Network Performance Monitor (NPM) 12.5. Rather than require users have a Ph.D. in SolarWinds Orion Platform product module versioning, wouldn't it be easier if those product modules compatible with each other all shared the same version number? Then it would be downright simple to identify IP Address Manager vX.XX wasn't compatible with User Device Tracker vY.YY or Network Configuration Manager vZ.ZZ.

 

Simplifying and consolidating our product module versioning is precisely what we aim to do in our next Orion Platform module releases. As you can imagine, this might come as a big surprise to many, which is why we've decided to notify the community in advance.

 

New releases for every Orion Platform product module going forward will now use the same versioning as the Orion Platform itself. This means the next release of Network Performance Monitor will not be v12.6 or v13.0, nor will any of the other Orion Platform product modules bear a resemblance to their current versioning. Instead, Orion Platform product module versions will be the four-digit year in which they were released, followed by the quarter of release. If there is a Service Release for a given module, it will appear in the third position following the quarter.

 

 

[YYYY.Q.SR]

 

If this all seems a bit confusing, fret not. You're probably already familiar with this versioning, as it's been the basis of the Orion Platform version for nearly a decade. This is also the same versioning used for Network Automation Manager.

 

 

What does this mean for my product modules?

 

To be completely honest, really nothing at all, aside from a departure from those products’ previous versioning schemes. It also means versioning is much more transparent and easier to relate to. For example, if you needed to know what version of Storage Resource Monitor (SRM) was released in October 2025, it’s now very easy: Storage Resource Monitor v2025.4. If you also needed to know what version of Server Configuration Manager (SCM) was compatible with SRM v2025.4, that too is now easy: SCM v2025.4, of course!

 

 

How will this affect previous releases?

 

In short, it doesn't. Currently released product module versioning will remain unchanged, though you can expect a fairly significant jump in version numbers the next time you upgrade.

 

 

I still have unanswered questions

 

You undoubtedly have a million questions related to this change racing through your brain right now. If not, perhaps later, after pondering this post for a while, a fantastic question pops to mind. In either scenario, post your questions related to this change in the comments section below.

Status is arguably one of the most important aspects of any monitoring solution. It's a key component for visually notifying you that something is amiss in your environment, as well as being an important aid in the troubleshooting process. When used properly, status is also the engine that powers alerting, making it an absolutely essential ingredient for both proactive and reactive notifications aimed at ensuring your entire IT environment runs smoothly.

 

Orion® Node Status, in particular, has for an extended period of time been somewhat unique when compared to other entities in the Orion Platform[MJ1] . Most other entities have a fairly simple, straightforward, and easy-to-understand hierarchy of status based upon severity. These include things like Up, Warning, Critical, and Down, but can also include other statuses which denote an absence of a state, such as Unknown, Unmanaged, etc. By comparison, a node managed in the Orion Platform today can have any of twenty-two unique statuses. Some of these statuses can, to the uninitiated, appear at best contradictory, and at worst, just downright confusing.

 

This is the result of separating information about the node itself from its associated child objects (like interfaces and applications) into multiple colored balls. The larger colored ball representing the reachability of the node, usually via ICMP, while the much smaller colored ball in the bottom right represents the worst state of any of the node's child objects.

 

 

Primary Node Status

Nodes With Child Status

 

It would be fair to say that this is neither obvious, nor intuitive, so in this release, we've sought to radically improve how Node status is calculated and represented within the Orion Platform.

 

 

Node Thresholds

 

The first thing people usually notice after adding a few nodes to the Orion Platform, is that node thresholds for things like CPU & Memory utilization appear to have no effect on the overall status of the node, and they'd be right. Those thresholds can be used to define your alerts, but node status itself has historically only represented the reachability of the node. That, unfortunately, complicates troubleshooting by obfuscating legitimate issues as well as adds unnecessary confusion. For example, in the image below, I'm often asked why the state of the node is “green” when the CPU Load and Memory utilization are obviously critical? A very fair and legitimate question.

 

 

 

With the release of Orion Platform 2019.2 comes the introduction of Enhanced Node Status. With this new Enhanced Node Status, thresholds defined either globally or on an individual node itself can now impact the overall status of the node. For example, if the memory utilization on a node is at 99% and your “Critical” threshold for that node is “Greater than 90%,” the node status will now reflect the appropriate “Critical” status. This should allow you to spot issues quickly without having to hunt for them in mouse hovers or drilling into Node Details views.

 

CPU Load

Memory Utilization

Response Time

Packet Loss

 

Sustained Thresholds

 

Borrowing heavily from Server & Application Monitor, Orion Platform 2019.2 now includes support for sustained node threshold conditions. Being notified of every little thing that goes bump in the night can desensitize you to your alerts, potentially causing you to miss important service impacting events. For alerts to be valuable, they should be actionable. For example, just because a CPU spikes to 100% for a single poll probably doesn't mean you need to jump out of bed in the middle of the night and VPN into the office to fix something. After all, it's not that unusual for a CPU to spike temporarily, or latency to vary from time to time over a transatlantic site-to-site VPN tunnel. 

 

What you probably want to be notified of instead is if that CPU utilization remains higher than 80% for more than five consecutive polls, or if the latency across that site-to-site VPN tunnel remains greater than 300ms for 8 out of 10 polls. Those are likely more indicative of a legitimate issue occurring in the environment that requires some form of intervention to correct.

 

 

Sustained Thresholds can be applied to any node's existing CPU Load, Memory Usage, Response Time, or Percent Packet Loss thresholds. You can also mix and match “single poll,” “X consecutive polls,” and “X out of Y polls” between warning and critical thresholds for the same metric for even greater flexibility. Sustained Thresholds can even be used in combination with Dynamic Baselines to eliminate nuisance alerts and further reduce alert fatigue, allowing you to focus only on those alerts which truly matter.

 

Null Thresholds

 

A point of contention for some users has been the requirement that all Node thresholds must contain some value. Those could be nodes that you still want to monitor, report, and trend upon those performance metrics but not necessarily be alerted on, such as staging environment, machines running in a lab, decommissioned servers, etc.

 

Historically, there has been no way to say, “I don't care about thresholds on this node”' or “I don't care about this particular metric.” At best, you could set the warning and critical thresholds as high as possible in the hopes of getting close to eliminating alerts for metrics on those nodes you don't necessarily care about. Alternatively, some customers update and maintain their alert definitions to exclude metrics on those nodes they don't want to be alerted on. A fairly messy, but effective, solution—but also one that is no longer necessary.

 

With the introduction of Enhanced Status in Orion Platform 2019.2, any Node threshold can now be disabled simply by editing the node and unchecking the box next to the warning or critical thresholds of the metric you're not interested in. Don't want a node to ever go into a “Critical” state as a result of high response time to keep the boss off your back, but still want to receive a warning when things are really bad? No worries, just disable the “Critical” threshold, leave the “Warning” threshold enabled and adjust the value to what constitutes “really bad” for your environment.

 

 

If so inclined, you can even disable these individual warning and critical thresholds globally from [Settings > All Settings > Orion Thresholds] for each individual node metric.

 

 

Child Objects

 

In this new world of Enhanced Status, no longer are there confusing multi-status icons, like “up-down” or “up warning.” Child objects can now influence the overall node status itself by rolling up status in a manner similar to Groups or how Server & Application Monitor rolls-up status of the individual component monitors that make up an Application. This provides a simple, consolidated status for the node and its related child entities. Those child objects can be things such as Interfaces, Hardware Health, and Applications monitored on the node, to name only a few.

 

Similar to Groups, we wanted to provide users with the ability to control how node status rollup was calculated on an individual, per-node basis for ultimate flexibility. When editing the properties of a single node or multiple nodes, you’ll now find a new option for “Status roll-up mode” where you can select from Best, Mixed, or Worst.

 

 

 

By altering how node status is calculated, you control how child objects influence the overall status of the node.

 

BestMixedWorst

 

Best status, as one might guess, always reflects the best status across all entities contributing to the calculation. Setting the Node to “Best” status is essentially the equivalent of how status was calculated in previous releases, sans the tiny child status indicator in the bottom right corner of the status icon.

 

Worst status, you guessed it, represents the status of the object in the worst state. This can be especially useful for servers, where application status may be the single most important thing to represent for that node For example, I'm monitoring my Domain Controller with Server & Application Monitor's new AppInsight for Active Directory. If Active Directory is “Critical,” then I want the node status for that Domain Controller to reflect a “Critical” state.

 

Mixed-status is essentially a blend of best and worst and is the default node status calculation. The following table provides several examples of how Mixed status is calculated.

 

Polled Status

Child 1 Status

Child 2 Status

Final Node Status

DOWNANYANYDOWN
UPUPUPUP
UP or WARNINGUPWARNINGWARNING
UP or WARNINGUPCRITICALCRITICAL
UP or WARNINGUPDOWNWARNING
UP or WARNINGUPUNREACHABLEWARNING
UPUPUNKNOWNUP
WARNINGUPUNKNOWNWARNING
UPUPSHUTDOWNUP
UP or WARNINGDOWNWARNINGWARNING
UP or WARNINGDOWNCRITICALCRITICAL
UP or WARNINGDOWNUNKNOWNWARNING
UP or WARNINGDOWNDOWNWARNING
UPUNKNOWNUNKNOWNUP
WARNINGUNKNOWNUNKNOWNWARNING
UNMANAGEDANYANYUNMANAGED
UNREACHABLEANYANYUNREACHABLE
EXTERNALANYANYGroup Status

 

In case you overlooked it in the table above, yes, External Nodes can now reflect an appropriate status based upon applications monitored on those nodes.

 

Child Object Contributors

 

Located under [Settings > All Settings > Node Child Status Participation] you will find you now have even more fine-grained, granular control of up to 27 individual child entity types that can contribute to the overall status of your nodes. Don't want Interfaces contributing to the status of your nodes? No problem! Simply click the slider to the “off” position and Interfaces will no longer influence your nodes status. It's just that easy.

 

Show me the Money!

 

You might be asking yourself, all these knobs, dials, and switches are great, but how exactly are these going to make my life better or simpler? A fair question, and one that no doubt has countless correct answers, but I'll try and point out a few of the most obvious examples.

 

Maps

 

One of the first places you're likely to notice Enhanced Status is in Orion Maps. The example below shows the exact same environment. The first image shows what this environment looked like in the previous release using Classic Status. Notice the absence of any obvious visual cues denoting issues in the environment. The next image to the right is of the very same environment taken at the exact same time as the image on the left. The only notable difference is that this image was taken from a system running Orion Platform 2019.2 with Enhance Node Status.

 

In both examples, there are the exact same issues going on in the environment, but these issues were obfuscated in previous releases. This made the troubleshooting process less intuitive and unnecessarily time-consuming. With Enhance Status, it's now abundantly clear where the issues lie. And with the topology and relationship information from Orion Maps, it's now easier to assess the potential impact those issues are having on the rest of the environment.

 

Classic Status

Enhanced Status

 

Groups

 

Groups in the Orion Platform are incredibly powerful, but historically in order for them to accurately reflect an appropriate status or calculate availability accurately, you were required to add all relevant objects to that group. This means you not only needed to add the nodes that make up the group, but also all child objects associated with those nodes, such as interfaces, applications, etc.

 

Even in the smallest of environments, this was an otherwise impossible feat to manage manually. Given the nature of all the various entity types that could be associated with those nodes, even Dynamic Groups were of little assistance in this regard. Enhanced Status not only radically simplifies group management, but it also empowers users to more easily utilize Dynamic Groups to make group management a completely hands-off experience.

 

The following demonstrates how Enhanced Node Status simplifies overall Group Management in the Orion Platform, reducing the total number of objects you need to manage inside those groups. The screenshot on the left shows a total of eight nodes using Enhanced Status in a group, causing the group to reflect a Critical status. The image to the right shows all the objects that are required to reflect the same status using Classic Status. As you can see, you would need to not only add the same 8 nodes but also their 43 associated child objects for a total of 51 objects in the group. Yikes!

 

Enhanced Status (8 Objects)

Classic Status (51 Objects)

 

By comparison, the following demonstrates what that group would look like with just the eight nodes alone included in the group using both Classic Status and Enhanced Status. Using Classic status, the group reflects a status of “Up,” denoting no issues at all in the group. With Enhanced Status, it's abundantly clear that there are in fact issues, which nodes have issues, and their respective severity. This aids in significantly reducing time to resolution and aids in root cause analysis.

 

Enhanced Status

Classic Status

 

Alerts

 

Possibly the greatest benefit of Enhanced Status is that far fewer alert definitions are required to be notified of the exact same events. Because node thresholds and child objects now influence the status of the node, you no longer need alert definitions for individual node metrics like “Response Time,” or related child entities like “Interfaces.” In fact, of the alert definitions included out-of-the-box with the Orion Platform, Enhanced Status eliminates the need for at least five, taking you from seven down to a scant two. That's a 71% reduction in the number of alert definitions that need to be managed and maintained.

 

Out-of-the-box Alerts Using Classic Status - x7

Out-of-the-box Alerts Using Enhanced Status - x2

 

Alert Macros

 

I'm sure at this point many of you are probably shouting at your screen, "But wait! Don't I still need all those alert definitions if I want to know why the node is in whatever given state that it's in when the alert is sent? I mean, getting an alert notification telling me the node is “Critical” is cool and all, but I sorta need to know why."

 

We would be totally remiss if in improving Node status we didn't also improve the level of detail we included in alerts for nodes. With the introduction of Enhanced Status comes two new alert macros that can be used in your alert actions, such as email notifications, which lists all items contributing to the status of that node. Those two alert macros are listed below.

 

The first is intended to be used with simple text-only notification mechanisms, such as SMS, Syslog, or SNMP Traps. The second macro outputs in HTML format with hyperlinks to each child objects respective details page. This macro is ideally suited for email or any other alerting mechanism that can properly interpret HTML.

 

  • ${N=SwisEntity;M=NodeStatusRootCause}
  • ${N=SwisEntity;M=NodeStatusRootCauseWithLinks}

 

The resulting output of the macro provided in the notification includes all relevant information pertaining to the node. This includes any node thresholds that have been crossed as well as a list of all child objects in a degraded state associated with the node, which is all consolidated down into a simple, easily digestible, alert notification that pinpoints exactly where to begin troubleshooting.

 

 

 

 

Enabling Enhanced Status

 

If you're installing any Orion product module for the first time that is running Orion Platform 2019.2 or later, Enhanced Status is already enabled for you by default. No additional steps are required. If you're upgrading from a previous release, however, you will need to enable Enhanced Status manually to appreciate the benefits it provides.

 

Because status is the primary trigger condition for alerts, we did not want customers who are upgrading to be surprisingly inundated with alert storms because of how they had configured the trigger conditions of their alert definitions. We decided instead to let customers decide for themselves when/if to switch over to Enhanced Status.

 

The good news is that this is just a simple radio button located under [Settings > All Settings > Polling Settings]

 

 

Conversely, if you decided to rebuild your Orion server and have a preference for “Classic” status, you can use this same setting to disable “Enhanced” Status mode on new Orion installations and revert back to “Classic” status.

 

 

Cautionary Advice

 

If you plan to enable “Enhanced” status in an existing environment after upgrading to Orion Platform 2019.2 or later, it’s recommended that you disable alert actions in the Alert Manager before doing so. This should allow you to identify alerts with trigger conditions in their alert definition that may need tweaking without inadvertently causing a flood of alert notifications or other alert actions from firing. Your coworkers will thank you later.

 

 

Feedback

 

Enhanced status represents a fairly significant, but vitally important, change for the Orion Platform. We sincerely hope you enjoy the additional level of customization and reduced management overhead it provides. As with any new feature, we'd love to get your feedback on these improvements. Will you be switching to Enhanced Status with your next upgrade? If not, why? Be sure to let us know in the comments below!

In addition to Node status improvements, the Orion® Platform 2019.2 includes a slew of other great new features and enhancements. There’s a tremendous amount of diversity in these improvements, ranging from deployment flexibility to usability all the way to security. So, no matter what your jam, this release for the Orion Platform is sure to have something for you.

 

 

 

Default Admin Password

 

If you're installing an Orion Platform product for the first time, perhaps on a lab system or in a staging environment, undoubtedly the first new thing you'll notice the first time you attempt to log in to the Orion web interface is you’re now required to define a password for the default “Admin” user account. No longer will you be able to login with the default “admin” account with no password. If you're upgrading from a previous release, however, this change won’t affect you. It's only applicable to new installs of the Orion Platform. However, if you're still running your Orion instance with no password defined for the “Admin” account, let this post serve as a reminder to check that off the to-do list.

 

Admin Password Change PromptError Returned When no Password is Entered

Azure SQL DB Support

 

In the earlier Orion Platform 2018.2 release, we added support for using Amazon Relational Database Service (RDS) as a cloud-based alternative to more traditional on-premises Microsoft SQL database servers. This allowed those customers who were deploying Orion instances into the cloud using Amazon Elastic Compute Cloud (EC2) as their infrastructure as a service solution, to lower costs and reduce management overhead further by using Amazon's database-as-a-service offering. As more organizations lift and shift workloads into the cloud, it's natural for their monitoring solution to be one of them.

 

Since that release, however, we've received numerous requests to provide similar support for Azure SQL DB, Microsoft's equivalent alternative service offering to Amazon's RDS… and in the Orion Platform 2019.4, we’ve delivered. By adding support for Azure SQL DB to all product modules running atop Orion Platform 2019.2, you’re now afforded greater deployment flexibility and choice than ever before, without the worry of being locked in to a single cloud vendor. Best of all, using Azure SQL DB as the SQL database repository for your Orion install is just as easy as using a local on-prem MSSQL database server instance.

 

Regardless if you're installing the Orion Platform for the first time or migrating your Orion instance to the cloud, the magic begins in the Configuration Wizard. Simply enter in the fully qualified domain name (FQDN) of the SQL Server instance as shown in your Azure Portal and your credentials. With the introduction of Azure SQL DB, the Orion Platform now also supports the use of Azure Active Directory credentials for authenticating to the Azure SQL DB instance should you prefer not to use SQL authentication.

 

 

If this is a new Orion Platform installation, you can create an empty database from within your Azure Portal for your Orion instance to use, or the Configuration Wizard can automatically create one for you, no differently than if you were to deploy the Orion Platform on-prem. By default, the Configuration Wizard will create an S3 tier database, the absolute lowest Azure SQL DB tier supported by the Orion Platform and its associated product modules.

 

My favorite thing about Azure SQL DB is how incredibly fast and easy it is to scale your database tier up or down from within the Azure portal as your needs (or budget) dictates.

 

If for any reason you forget which Azure SQL database tier the Orion Platform is using, you can remind yourself from within the comfort of the Orion web interface simply by going to [Settings > All Settings > Database Details].

 

 

Orion Agent Rediscovery

 

Rediscovering things like newly added volumes, AppInsight applications, and interfaces on Agents has historically been a fairly binary operation. Your options were either to run a rediscovery against every Agent-managed node associated with a given Polling Engine, or none. There wasn’t really a way to specify additional criteria to narrow your rediscovery job to a subset of Agent-managed nodes. This was obviously fairly limiting if you wanted to handle some Agent-managed nodes differently than others, such as production vs. staging/lab machines or by office/region. If you wanted these handled differently, your only recourse was to divvy those Agents up across polling engines based on their role or location.

 

Since this was hardly an ideal solution for some customers, or even an option for others, we knew we could do better. In Orion Platform 2019.2, you can now specify rediscovery parameters for Agent-managed nodes based on node properties, such as IP addressing, node caption naming conventions, and even custom properties. These properties can even be combined to target a subset of Agents you want to be rediscovered, either one time or on a recurring basis. You'll even find a convenient “Preview” button so you can validate the rediscovery parameters you've specified to return the expected Agent-managed nodes. Coupled with automatic import, these Agent rediscovery options provide the Ronco Rotisserie equivalent of IT management, allowing you to simply set it and forget it.

 

Linux Agent Metrics

 

More than a few keen-eyed observers have noticed a slight discrepancy when monitoring Linux nodes using the Agent when compared to those same nodes being monitored via SNMP. Namely, the absence of specific volume types, such as Swap Space, Shared Memory, Memory Buffers, and more. Fortunately, in this release, we've corrected this injustice and now provide visibility into the same volume types with the Linux Orion Agent as are available when polling via SNMP. No longer will you need to make difficult compromises or tradeoffs when deciding to switch your node polling method from SNMP to the Linux Agent.

 

Orion Platform 2018.4Orion Platform 2019.2

 

Orion Agent SDK

 

Since the initial first release of the Orion Agent, it's been possible to use the Orion SDK to script the push deployment of new agents to remote machines no differently than you can through the Orion web interface. While this has been great, those systems have to be accessible via RPC and WMI for Windows or SSH for Linux for the agent to be deployed. Additionally, those machines where the Agent is deployed must be able to communicate back to the Orion server or one of its associated polling engines. For those customers who would prefer to pre-deploy the Agent in a passive mode (server initiated), either using Chef, Puppet, SCCM, or even SolarWinds Patch Manager, there hasn’t really been any good way to script or automate managing those systems. Instead, users have had to add those passive agents to the Orion Platform manually, one by one. Which is perhaps fine if you have the occasional one or two, but not so much fun when you have dozens or even hundreds of newly deployed Agents to manage in your Orion instance.

 

With Orion Platform 2019.2, this is now a problem of the past. You can now fully script and automate adding passive agents to your Orion instance using the Orion SDK. Simply pass all the same parameters you would normally be prompted to enter when adding a passive agent through the Orion web interface as part of your script. For example, the IP address of the machine where the passive agent is already deployed. Within seconds of executing your script, you should see your passive agent appear under [Settings > All Settings > Manage Agents] of the Orion web interface.

 

 

 

Manually Provision Agent Plugins

 

Some organizations have offices in very remote regions of the world where latency is very high and bandwidth is a sparse, precious commodity. While the Orion Agent is extremely lightweight to deploy and bandwidth-efficient during normal operation, when the Agent is initially provisioned, it downloads any and all dependencies necessary to perform whatever function it has been asked to do, such as functioning as a QoE sensor, NetPath probe, or becoming a managed node, to name only a few uses for the Agent.

 

Depending on which functions are being used, the age of the operating system, and how up-to-date the machine is with Windows Updates, the Agent plugin dependencies can reach up to a couple of hundred megabytes in size. If you need to provision dozens of Agents in one of these remote regions with high latency connections and very little bandwidth, it can take a very long time before all those Agents finish downloading all necessary plugins and dependencies (if they don't give up before then). Worse yet, if you're doing this deployment during working hours, the download of plugins and dependencies for all those Agents can significantly impede other people's ability to function in the office, as all available bandwidth could be consumed by those Agents attempting to download their plugins and plugin dependencies.

 

After upgrading to Orion Platform 2019.2, you’ll be able to pre-provision all Agent plugins and their related dependencies, thus eliminating the need for them to be downloaded from their associated polling engine as well as the potential to impact end users working in that remote office during the Agent provisioning process.

 

To get started, simply copy the contents of the “C:\Program Files (x86)\SolarWinds\Orion\AgentManagement\Plugins”' directory on the main Orion server to the “C:\ProgramData\SolarWinds\Agent\Plugins” directory of the Windows machine where you want to deploy the Agent. How you get those files to their intended destination is entirely up to you. You can use a CD, DVD, USB drive, even a local file share (or can I plug the tried-and-true Serv-U® MFT file transfer solution).

 

Once the agent plugins and their related dependencies have been copied to the appropriate directory on the remote machine where the Agent will be installed, install and configure the Agent as you normally would. The Agent should now use the local plugin repository rather than downloading those plugins across the wire from the polling engine with which it's associated. If you're pre-provisioning Linux or AIX Agents, you can follow the same steps. The only difference is the directory where the agent plugins are stored. For Linux or AIX Agents, be sure to copy them to the “/opt/SolarWinds/Agent/bin/Plugins” directory.

 

This same method can be used when upgrading Agents using a package management or software distribution solution like SolarWinds Patch Manager or Microsoft SCCM. Simply deploy the contents of the “C:\Program Files (x86)\SolarWinds\Orion\AgentManagement\Plugins” directory from the main Orion server to the appropriate directory listed above on the machine where the Agent is installed. Then execute the unattended Agent upgrade process as you normally would.

 

 

 

Continuing on the momentum of the previous release, Orion Platform 2019.2 adds even more direct links to PerfStack, where you can cross-correlate metrics across a variety of different entities and entity types to quickly identify the root cause of issues in your environment. Now, simply click on the numeric value or linear gauge in any of the 30 updated resources and you’ll be launched directly into PerfStack, where metrics are automatically plotted for you over time, ready for you to begin your analysis.

 

 

The following table lists all 30 Orion resources updated in this release to link their respective metrics directly to PerfStack.

 

New Resources Supporting Direct Links to PerfStack
Top 10 Avg. Disk sec/TransferTop 25 Avg. Disk sec/TransferTop XX Avg. Disk sec/Transfer
Top 10 Nodes by Average Response TimeTop 25 Nodes by Average Response TimeTop XX Nodes by Average Response Time
Top 10 Nodes by Average CPU LoadTop 25 Nodes by Average CPU LoadTop XX Nodes by Average CPU Load
Top 10 Disk Queue LengthTop 25 Disk Queue LengthTop XX Disk Queue Length
Top 10 Volumes by Disk Space UsedTop 25 Volumes by Disk Space UsedTop XX Volumes by Disk Space Used
Top 10 Nodes by Percent Memory UsedTop 25 Nodes by Percent Memory UsedTop XX Nodes by Percent Memory Used

Top 10 Nodes by Percent Packet Loss

Top 25 Nodes by Percent Packet LossTop XX Nodes by Percent Packet Loss
Top 10 Nodes by Current Response TimeTop 25 Nodes by Current Response TimeTop XX Nodes by Current Response Time
Top 10 Total IOPSTop 25 Total IOPSTop XX Total IOPS
Nodes with High Average CPU LoadVolumes with High Percent UsageNodes with High Memory Utilization

 

 

Automatic Removal of Unknown Volumes

 

In today's highly virtualized word, volumes are no longer the physical, heavy-metal rectangle components of the server seldom, if ever, removed or added from the machine. Instead, volumes are simply additional storage capacity easily added or removed on a whim with just a few mouse clicks or keystrokes. As such, it's not uncommon these days for new volumes to be added or removed as storage capacity needs change over the course of a server's lifecycle. This, however, results in some additional overhead to keep the monitoring server up-to-date with these changes in the environment. While scheduled recurring discoveries with automatic import helps address automating the monitoring of new volumes as they're added to servers in the environment, removed volumes remain managed in the Orion Platform until they're manually deleted by someone with Node Management rights. Hunting down all these “unknown” volumes can also be a tedious process, which is why it's seldom done. The result is wasted volume licenses and bogged down polling engines wasting polling cycles by trying to monitor volumes that will never return.

 

 

In our never-ending quest to reduce management overhead, we’ve now added the ability to automatically remove these “unknown” volumes after a predetermined period of time, which is, of course, user-configurable.

 

Under [Settings > All Settings > Orion Polling Settings], you’ll find a new option intuitively entitled “Automatically Remove Unknown Volumes,” which, as the name suggests, will remove any volumes from being managed by the Orion Platform if they’ve been “unknown” for longer than the number of days defined in “Remove Unknown Volumes After” field. To ensure we’re not inadvertently removing “unknown” volumes you may not want to be deleted immediately upon upgrading to Orion Platform 2019.2,, we’ve disabled this option by default. We do, however, recommend enabling this option and removing “unknown” volumes after a reasonable number of days as part of good monitoring hygiene.

 

 

Secure Syslog Alerts

 

For several years it's been possible to send SNMP Traps securely using SNMPv3 as an alert action. There has, however, not been any equivalent for sending Syslog messages as part of an alert trigger action in a similarly secure fashion… until now.

 

With the release of Orion Platform 2019.2, you’ll now find a new option to send Syslog messages via TCP, not just UDP, as in previous releases. There’s also an option for sending those Syslog messages via TCP using TLS encryption, providing secure communications and data privacy for data in motion. With these new capabilities, you can now safely and securely send alerts via Syslog to other Syslog receivers like Kiwi Syslog® or another Orion instance running Log Analyzer via TCP for improved reliability of message delivery and TLS encryption to comply with your latest security policies and regulatory mandates.

 

 

HSRP Addresses

 

Odd as it may seem, IP addresses configured on Cisco routers for use with HSRP are not expressed using the traditional industry standard MIB2 ipAdEntAddrhttp://oid-info.com/get/1.3.6.1.2.1.4.20.1.1 OID. This information is instead tucked away in Cisco's private cisco-hsrp-mib, out of reach from the Orion Platform's normal mechanisms for gathering IP addresses assigned to a node. This meant it wasn’t possible to search for a node via the “Search for Nodes” resource using any HSRP IP address configured on a device. It also meant any Orion product module attempting to associate information to a given Node via its HSRP address, like NetPath, was unable to because the Orion Platform was unaware of the node's HSRP addresses.

 

Fortunately for you, this is now a thing of the past. With Orion Platform 2019.2, it will now collect all HSRP addresses assigned to a given node, allowing you to quickly find nodes by their HSRP addresses and properly associating disparate information from Orion product modules to its associated node.

 

FortiGate CPU & Memory

 

Those of you running FortiGate firewalls in your environment should be pleased to hear Orion Platform 2019.2 now natively supports monitoring of both CPU and memory utilization for these devices out-of-the-box. No longer will you need to fumble with Universal Device Pollers. Best of all, you can even monitor these metrics in real-time via PerfStack Real-Time Polling.

 

If you're already monitoring your FortiGate firewalls with your Orion instance via SNMP, there's nothing additional you need to do. Simply upgrade your Orion product module to the latest version that includes Orion Platform 2019.2, and these metrics will begin being collected. If you were previously using Universal Device Pollers to monitor the CPU and memory utilization on your FortiGate firewalls, you may want to consider removing those pollers after upgrading to reduce polling overhead.

 

 

 

Dynamic External Nodes

 

For years now, the Orion Platform has had the notion of External Nodes, which essentially represents a node that typically isn’t owned or managed by you and doesn’t respond to ICMP, SNMP, or WMI. The primary purpose of external nodes is for assigning application templates from Server & Application Monitor. Those application templates are commonly HTTP/HTTPS User Experience Monitors or TCP Port Monitors for monitoring external websites and SaaS applications, but there are many more uses for External Nodes. These are simply two examples.

 

 

The trouble with external nodes historically has been since they don't poll any information, they also don't update their IP address—you must edit the properties of an External Node and select “Dynamic IP.” In previous Orion releases, you couldn't have external nodes with dynamic IP addresses. So, if you’d assigned an application template to an external node and its IP address ever changed, it would report a “down” status even if the application being monitored was really “up.” The Orion Platform was still polling the application using the original IP address of the node prior to it changing. Your only recourse for correcting this issue was to delete the node, re-add it to your Orion instance, and reassign any application templates you had assigned while losing any historical data for the applications monitored on the node.

 

With the release of Orion Platform 2019.2, we have addressed this glaring limitation of external nodes. Now, when the “Dynamic IP Address” box is checked on an “External” node, a reverse lookup against the hostname or fully qualified domain name (FQDN) for the node is done every two minutes by default, automatically updating the IP address. The frequency in which this query is done can be adjusted simply by updating the “Node Status Polling” interval for the node.

 

 

Newly Added SysObjectIDs

 

Every release of the Orion Platform includes support for identifying new makes, models, and manufacturers of devices. This comes in large part from customers just like you who help identify these new devices in the wild and report them to us in the Tell Us Your Unknown Devices v2.0 thread.

 

The following is a list of all new devices that will now be properly identified by Orion Platform 2019.2. If you're running the latest release of the Orion Platform and the “Machine Type” for any of your devices is reported as “Unknown,” simply post its SysObjectID to the Tell Us Your Unknown Devices v2.0 thread along with its make, model, and manufacturer, and we’ll ensure it's properly identified as such in the next release of the Orion Platform.

 

Cisco 800M with 8-Port LAN Integrated Services RouterCisco C1111-8PLTELAWH Router
DELL S5000Cisco C1111-8PLTELAWF Router
DELL S4810-ONCisco C1111-8PWE Router with WLAN E domain
DELL S6000-ONCisco Aironet 1815
DELL S4048-ONCisco Aironet 1540
DELL S3048-ONCisco Catalyst 2960L-24TQ-LL Switch
DELL S3148PCisco Catalyst 2960L-48TQ-LL Switch
DELL S3124PCisco Catalyst 2960L-24PQ-LL Switch
DELL S3124FCisco Catalyst 2960L-48PQ-LL Switch
DELL S3124Cisco Catalyst 9407R Switch
DELL S6100Cisco Catalyst 94010R Switch
DELL S6010Cisco C1111-4P Router
DELL S4048TCisco C1111-4PLTEEA Router with Multimode Europe and North America Advanced LTE
DELL S3148Cisco C1111-4PLTELA Router with Latin America Multimode and Asia Pacific Advanced LTE
DELL Z9500Cisco C1111-4PWE Router with WLAN E domain
DELL Z9100Cisco C1111-4PWB Router with WLAN B domain
DELL S4148FCisco C1111-4PWA Router with WLAN A domain
DELL S4148TCisco C1111-4PWZ Router with WLAN Z domain
HP 2930F-24G-PoE+-4SFP (JL261A)Cisco C1111-4PWN Router with WLAN N domain
1920S 24G 2SFP PoE+ (JL385A)Cisco C1111-4PWQ Router with WLAN Q domain
ForeScout CounterACT ApplienceCisco C1111-4PWH Router with WLAN C domain
Corvil CNE ApplianceCisco C1111-4PWR Router with WLAN R domain
Corvil CNE ApplianceCisco C1111-4PWF Router with WLAN K domain
FortiWeb 1000DCisco C1111-4PWD Router with WLAN D domain
Fortinet Fortigate 280D-POECisco C1116-4P Router with VDSL/ADSL
FortiGate 500DCisco C1116-4PLTEEA Router with Multimode Europe and North America Advanced LTE
FortiGate 600DCisco C1117-4P Router with VDSL/ADSL
FortiWeb 4000DCisco C1116-4PWE Router with WLAN E domain
Pulse Secure IC4000Cisco C1117-4PLTEEA Router
Pulse Secure MAG-2600Cisco C1117-4PLTELA Router
Pulse Secure PSA-3000Cisco C1117-4PWE Router with WLAN E domain
Pulse Secure PSA-5000Cisco C1117-4PWA Router with WLAN A domain
Pulse Secure PSA-7000cCisco C1117-4PWZ Router with WLAN Z domain
Pulse Secure PSA-7000fCisco C1117-4PM Router with VDSL/ADSL
9982P2ETCisco C1117-4PMLTEEA Router
IAP-325Cisco C1117-4PMWE Router with WLAN E domain
IAP-315Cisco C1112-8P Router
ClearPass Policy Manager CP-HW-5KCisco C1112-8PLTEEA Router with Multimode Europe and North America
6548 SwitchCisco C1113-8P Router
Internal Management Module SwitchCisco C1113-8PM Router with VDSL/ADSL
AnnuncicomCisco C1113-8PLTEEA Router
InstreamerCisco C1113-8PLTELA Router
DataDomain 9300Cisco C1113-8PMLTEEA Router
S6720-54C-EI-48S-ACCisco C1113-8PWE Router with WLAN E domain
Lantronix EDS4100Cisco C1113-8PWA Router with WLAN A domain
Xerox DocuColor 242Cisco C1113-8PWZ Router with WLAN Z domain
ColorQube 9301Cisco C1113-8PMWE Router with WLAN E domain
D110Cisco C1113-8PLTEEAWE Router
Palo Alto PA-5200Cisco C1113-8PLTELAWE Router
Palo Alto PA-5200Cisco C1113-8PLTELAWZ Router
Palo Alto PA-220Cisco C1114-8P Router
H3C S5560-54C-EICisco C1114-8PLTEEA Router with Multimode Europe and North America
H3C S12504X-AFCisco C1115-8P Router
H3C S6520-48S-EICisco C1115-8PLTEEA Router with Multimode Europe and North America Advanced LTE
LP-1030Cisco C1115-8PM Router with VDSL/ADSL
TSM-24-DPSCisco C1115-8PMLTEEA Router
VMR-HD4D30Cisco C1118-8P Router(ciscoC11188P)
NPS-8-ATSCisco C1116-4PLTEEAWE Router
vMXCisco C1117-4PLTEEAWE Router
Juniper Virtual Route Reflector (vRR)Cisco C1117-4PLTEEAWA Router
Juniper ACX2200Cisco C1117-4PLTELAWZ Router
Juniper ACX5048Cisco C1117-4PMLTEEAWE Router
Juniper ACX5096Cisco 807 Industrial Integrated Services Routers
Juniper vSRXCisco 807 4G LTE Industrial Integrated Service Router
Juniper SRX345Cisco 807 4G LTE Industrial Integrated Service Routers with multi-mode  Global (Europe & Australia) LTE/HSPA+
Juniper ACX2100Cisco 807 4G LTE Industrial Integrated Service Router
Juniper ACX1100Cisco 807 4G LTE Industrial Integrated Service Routers with multi-mode  AT&T and Canada  LTE/HSPA+
Juniper EX3400-24TCisco Catalyst 9500 series with 32 Ports of 100G/32 Ports of 40G
Juniper QFX10002-72QCisco Catalyst 9500 series with 32 Ports of 40G/16 Ports of 100G
Juniper QFX10008Cisco Catalyst 9500 series with 48 Ports of 1G/10G/25G + 4 Ports of 40G/100G
WIB 8000Cisco Catalyst 9500 Router with 24 Ports of 1G/10G/25G + 4 Ports of 40G/100G
Meraki DashboardCisco Catalyst 9500 Series Switch
Xerox ApeosPort-IV C3375C9500-16X
Xerox ApeosPort-V C6675 T2IR829M-LTE-LA-ZK9
DCS-7060CX2-32SCisco C1109-2PLTEGB 2 ports GE LAN M2M Router with Multimode LTE WWAN Global
SX6036Cisco C1109-2PLTEUS 2 ports GE LAN M2M Router with Multimode LTE WWAN US
SX6036Cisco C1109-2PLTEVZ 2 ports GE LAN M2M Router with Multimode LTE WWAN Verizon
MSB7800-ES2FCisco C1109-2PLTEAU 2 ports GE LAN M2M Router with Multimode LTE WWAN Australia and New Zealand
F5 BIG-IP 10350vCisco C1109-2PLTEIN 2 ports GE LAN M2M Router with Multimode LTE WWAN India
BIG-IP i2800Cisco C1101-4P 4 Ports GE LAN Router
F5 Networks BIG-IP i4600Cisco C1101-4PLTEP 4 Ports GE LAN Router
Delphix DB EngineCisco C1101-4PLTEPWE 4 Ports GE LAN Router
TSC ME240Cisco C1101-4PLTEPWB 4 Ports GE LAN Router
Dell S4048-ONCisco C1101-4PLTEPWD 4 Ports GE LAN Router
Dell S6000-ONCisco C1101-4PLTEPWZ 4 Ports GE LAN Router
CX923deCisco C1101-4PLTEPWA 4 Ports GE LAN Router
OmniSwitch 6450-48LCisco C1101-4PLTEPWH 4 Ports GE LAN Router
OmniSwitch 6450-P10Cisco C1101-4PLTEPWQ 4 Ports GE LAN Router
Alcatel OmniSwitch 6450-C48XCisco C1101-4PLTEPWR 4 Ports GE LAN Router
Alcatel OmniSwitch 6450-P48XCisco C1101-4PLTEPWN 4 Ports GE LAN Router
Alcatel OmniSwitch 6450-U24Cisco C1101-4PLTEPWF 4 Ports GE LAN Router
Alcatel OmniSwitch 6350-P48Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2P)
OmniSwitch 6860E-U28Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWB)
InfoBlox ND-1400Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWE )
TelePresence MCU 5320Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWD)
Cisco IE 2000-16PTC-G-NX Industrial Ethernet SwitchCisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWZ)
Cisco IE 2000-4S-TS-G-L Industrial Ethernet SwitchCisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWA)
Cisco IE-2000U-4S-G Industrial Ethernet SwitchCisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWH)
Cisco C887VAM Integrated Series RoutersCisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWQ)
Cisco 897 Multi-Mode VDSL2/ADSL2+ POTS Annex M with Multi-Mode 4G LTE RouterCisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(iscoC11094PLte2PWN)
Cisco C899 Secure Gigabit Ethernet with Multi-mode 4G LTE RouterCisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWR)
Aironet 1572EC Outdoor Access PointCisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWF)
Cisco Catalyst 6824-X-LE-40GCisco C9407R
Cisco Firepower NGFW 4140Cisco 1000V
Cisco NCS 5001Cisco Nexus 3132Q Switch
Cisco NCS 5002Cisco UCS 6332 32-Port Fabric Interconnect
Cisco 897 Multi-mode VDSL2/ADSL2+ POTS with Multi-Mode 4G LTE RouterCisco Nexus 5672UP Switch
Cisco NCS 1002UCS 6332-16UP Fabric Interconnect
Cisco NCS 5508Cisco Nexus 31128PQ Switch
Cisco NCS 5502-SECisco Nexus 3132
Cisco 897VAGLTELAK9-4G LTE Latin America router with 1 Giga Ethernet WANCisco Nexus 3172
Cisco 819 Non-Hardened 4G LTE M2M with Dual Radio 802.11n WiFi RouterCisco Nexus 3172
Cisco 819 Non-Hardened 4G LTE M2M with Dual Radio 802.11n WiFi RouterCisco Nexus Nexus 9236C
Cisco Aironet 1560Cisco Nexus 31108PC-V
C899G-LTE-LA-K9 4G router with 1 Giga Ethernet WAN, 1 SFP (Small Form-factor Pluggable) Giga Ethernet WANCisco 3172
C819G-LTE-LA-K9 Router with 1 Gigabit Ethernet WAN, 4 Fast Ethernet LANCisco 9232C
Cisco 4221 ISRNexus 93180YC-FX
Cisco 4221 Integrated Services RouterNexus 9348GC-FXP
Cisco Catalyst CDB-8U SwitchCisco Nexus 9K C9364C
Cisco Catalyst CDB-8P SwitchCisco 7600 Series Route Switch Processor 720 with 10 Gigabit Ethernet Uplinks
Cisco NCS 5501WS-X45-SUP9-E (Cisco Catalyst 4503-E  Switch Module )
Cisco NCS 5502Cisco 3172
Cisco 829 4G LTE Industrial Integrated Service RouterCisco SGE2000 10/100/1000 Ethernet Switch
Cisco 829 4G LTE Industrial Integrated Service Routers with multi-mode LTE/HSPA+ with 802.11nSF550X-24
Cisco 829 4G LTE Dual-modem Industrial Integrated Service RouterSF550X-24P
Cisco 829 4G LTE Dual-modem Industrial Integrated Service Routers with multi-mode LTE/HSPA+ with 802.11nSF550X-24MP
Cisco 809 4G LTE Industrial Integrated Service RouterSF550X-48
Cisco 809 4G LTE Industrial Integrated Service Routers with multi-mode LTE/HSPA+SF550X-48P
Cisco C1111-8P RouterSF550X-48MP
Cisco C1111-8PLTEEA Router with Multimode Europe and North America Advanced LTESG550X-24
Cisco C1111-8PLTELA Router with Latin America Multimode and Asia Pacific Advanced LTESG550X-24P
Cisco C1111-8PWE Router with WLAN E domainSG550X-24MP
Cisco C1111-8PWB Router with WLAN B domainSG550X-24MPP
Cisco C1111-8PWA Router with WLAN A domainSG550X-48
Cisco C1111-8PWZ Router with WLAN Z domainSG550X-48P
Cisco C1111-8PWN Router with WLAN N domainSG550X-48MP
Cisco C1111-8PWQ Router with WLAN Q domainSG350X-24
Cisco C1111-8PWH Router with WLAN C domainSG350X-24PD 24-Port 2.5G PoE Stackable Managed Switch
Cisco C1111-8PWR Router with WLAN R domainSG350X-24P
Cisco C1111-8PWF Router with WLAN K domainSG350X-24MP
Cisco C1111-8PLTEEAWE RouterSG350X-48
Cisco C1111-8PLTEEAWB RouterSG350X-48P
Cisco C1111-8PLTEEAWA RouterSG350X-48MP
Cisco C1111-8PLTEEAWR RouterSG350X-8PMD 8-Port 2.5G PoE Stackable Managed Switch
Cisco C1111-8PLTELAWZ RouterSG350-8PD 8-Port 2.5G PoE Managed Switch
Cisco C1111-8PLTELAWN RouterPravail NSI
Cisco C1111-8PLTELAWQ Router

 

 

But Wait, there's more!

 

The list of improvements above is just a small sampling of everything included in the Orion Platform 2019.2 release. There are still plenty of additional new features and improvements added to this release of the Orion Platform, including Enhanced Node Status, Orion Maps 2.0, and Install/Upgrade Improvements. As always, we appreciate your feedback on all these improvements, so be sure to let us know your thoughts in the comment section below.

If you have installed or upgraded any Orion® Platform product module over the course of the last six months and were running Orion product modules on either Windows Server 2012, Windows Server 2012 R2, or SQL Server 2012, you probably noticed an ominous warning message notifying you that these operating system and SQL database versions are deprecated and will no longer be supported in a forthcoming release.

 

Windows Server 2012 / R2 Deprecation NoticeMicrosoft SQL Server 2012 Deprecation Notice

 

 

If you didn’t encounter this message during your latest upgrade or install, not to worry. The above message only appears if Orion product modules are being installed or upgraded on an operating system or SQL database version that has been deprecated. If you're running several versions behind but have been keeping tabs on the release notes, eyeing all the wonderful features that await you when you do your next upgrade, you will find a similar deprecation verbiage there for every Orion module letting you know that you should upgrade from Windows Server 2012, Server 2012 R2, and SQL 2012 at your earliest convenience to stay current with later releases.

 

 

So what exactly is the purpose of these deprecation notices and why should I care?

 

Deprecation notifications such as these serve as sign postings to our customers of important impending changes in the matrix of operating systems and SQL database versions that will no longer be supported in future releases. These types of advanced notices were introduced at the request of customers like you. Their intention is to allow you ample opportunity to upgrade your environment prior to the release of newer Orion product module versions where these operating systems and database versions may no longer supported.

 

 

Life before Deprecation Notices

 

Prior to the inclusion of these deprecation notices, the only real way of knowing if an operating system or database version was no longer supported in the latest release of the Orion Platform was to download and attempt to install it. This was obviously much too late in the process, as by this point you likely only received approval from the change advisory board to upgrade your Orion install, and your window for downtime was narrow enough only to allow for the upgrade of your Orion product modules and not the operating system or database server that your Orion Platform resided upon. As you could imagine, this was a frustrating or even downright infuriating time to find out your upgrade was blocked. To prevent these types of mishaps from occurring, SolarWinds provides in-product deprecation notices one version in advance, warning customers that future releases are unlikely to support these older operating systems or SQL database versions.

 

 

My OS or SQL database version has been deprecated. How am I affected?

 

In short, you're probably not. These deprecation notices apply only to the absolute latest releases and are not applicable to previous versions of the product. There has always been zero requirement that customers upgrade to the latest version to continue receiving support. While we welcome and encourage all our customers to take full advantage of the latest enhancements and improvements included in newer versions of the product, this is not always possible or practical in every customer environment. Some organizations even have firm constraints that require them to stay at least one version behind the latest at all times.

 

For those reasons and more, we continue to fully support several previous released versions of Orion product modules at any given time. Suffice to say, if you're currently running NPM 12.3 or any other Orion Platform 2018.2 module release on Windows Server 2012, 2012 R2, or SQL 2012, there is no immediate impending requirement to upgrade. SolarWinds end-of-life policy helps ensure that these versions will remain fully supported, even when installed on Server 2012, 2012 R2, or SQL 2012.

 

 

Why are you deprecating my otherwise perfectly fine operating system or SQL database version?

 

Going forward, the Orion Platform and its related modules will begin to leverage new technologies only available in newer versions of SQL and Windows. New capabilities such as In-Memory OLTP, columnstore indexes, as well as partitioned tables and indexes aim to improve various aspects of performance and scalability for the entire Orion Platform, as well as the modules installed atop it. This will allow for accelerated website performance, shorter nightly database maintenance routines, reduced database size, and faster report generation, to name only a few areas of noticeable improvement.

 

Windows Server 2016 and 2019, as well as the version of IIS included with them, provide a host of important new security improvements that are critical to organizations of all sizes. These include things like supporting newer, stronger encryption ciphers, HTTP Strict Transport Security (HSTS) enabled websites, secure cookies, and more. While patches for specific critical security vulnerabilities will still be made available for Windows Server 2012 and 2012 R2, vital new security enhancements, bug fixes, and other notable improvements will only be available to later versions of the Windows operating system still under mainstream support.

 

 

How can I better plan for possible future OS and SQL deprecations?

 

While SolarWinds does everything reasonably possible to help ensure customers stay well informed of impending deprecations, some have asked for a longer-term outlook so they can plan their upgrade and server migration schedules accordingly. First, when selecting which operating system or database version to install Orion product modules on, we always recommend using the latest possible version of both. This decreases the likelihood of that operating system or database version being deprecated anytime in the foreseeable future, while also limiting the number of times you need to migrate your Orion installation to a newer server throughout its lifetime. To stay proactively ahead of any impending deprecation notices, however, you need only look to Microsoft's published product lifecycle for Windows and SQL Server.

 

Put simply, the Orion Platform will support Windows operating system and SQL database versions covered under Microsoft's Mainstream support that are available at the time of that versions GA release date.

 

 

I still have Windows and SQL 2012 in my environment. Can I continue monitoring those systems with Orion?

 

Absolutely! Monitoring Windows Server 2012 and SQL 2012 systems with the Orion Platform and its related modules remains fully supported, even in the latest releases. This support also extends to those systems monitored using the Orion Agent.

 

 

What Windows and SQL server versions exactly should I expect will be supported in the release following Orion Platform 2018.2?

 

The following table outlines those versions of SQL and Windows Server that will be supported in the Orion Platform release following version 2018.2:

 

Supported Operating System VersionsSupported Microsoft SQL Server Versions
Windows Server 2016SQL 2014
Windows Server 2019SQL 2016
SQL 2017
Amazon RDS

 

 

I'm currently on Windows or SQL Server 2012. How do I upgrade?

 

In recent years, Microsoft has made the in-place upgrade process easier and more reliable than ever. In-place upgrades are likely also the fastest method for getting your Orion server up to the latest operating system or SQL database version. If an in-place upgrade isn't for you, SolarWinds provides a wealth of documentation on migrating your Orion Platform to a new server.

 

 

Also in the Success Center, you will find documentation on migrating your Orion database to a new SQL Server.

 

 

 

I need assistance with my next Orion upgrade, what options do you provide?

 

If you need a refresher course on the upgrade process, or a confidence boost that you're on the right track, you will find on-demand training videos and instructor-led virtual online classes you can attend for free through the Customer Portal. As always, if at any time you encounter an issue during your upgrade, don't hesitate to contact SolarWinds support for assistance. We are here 24 hours a day, seven days a week, 365 days a year to help ensure you are successful using SolarWinds products.

 

The SolarWinds trademarks, service marks, and logos are the exclusive property of SolarWinds Worldwide, LLC or its affiliates.  All other trademarks are the property of their respective owners.

If you've been using the SolarWinds® Orion® unified IT monitoring platform for more than a few years, it's likely that you've at least once migrated it to a new server. You may have migrated from a physical server to a virtual one, or perhaps you simply needed to migrate to a server running a more modern operating system. Regardless of the reason, you're likely aware that there's a litany of documentation and training videos on the subject. Below are just a few, in case you’re curious.

 

 

Index

 

Deprecation

 

Now, as many of you have likely discovered during your last upgrade to SolarWinds® Network Performance Monitor (NPM) 12.3, SolarWinds® Server & Application Monitor (SAM) 6.7, or any other product modules released in 2018, support for Windows Server 2012, Server 2012 R2, and SQL Server 2012 were officially deprecated in those releases. You may have stumbled upon that when reviewing the release notes, or during the pre-flight checklist when running the installer.

 

Deprecation does not mean that those versions aren’t supported with Network Performance Monitor 12.3, Server & Application Monitor 6.7, etc. Deprecation simply means that new versions released in the future are unlikely to support those older operating systems. These deprecation notices were added at the request of customers like yourself, who asked to be provided with advance notice when future versions of Orion product modules would no longer run on older operating systems or SQL database versions. Those deprecation notices serve to allow customers an opportunity to budget and plan for these changes accordingly, rather than find out during a 3 a.m. change window that the upgrade you planned doesn't support your current OS or database version.

 

While future product module versions may no longer support Windows Server 2012, Server 2012 R2, or SQL Server 2012, that doesn't mean all previous versions are no longer supported at all. In fact, the latest, currently shipping versions of NPM, SAM, and other SolarWinds products are planned to continue to support running on Windows Server 2012 and 2012 R2 for many more years to come. So, if you're happy with the versions of product modules you're running today, take your time and don't rush your OS upgrade or server migration. Plan it appropriately. We'll still be here, waiting with a boatload of awesome new features whenever you're ready to upgrade.

 

Preface

 

But I digress. Since many of you have planned, or will eventually be planning, to migrate your Orion Platform to Server 2016 or perhaps even Server 2019, this inevitably stirs up painful memories of migrations you have undoubtedly done in the past—whether that was the Orion Platform specifically or some other mission-critical system in your environment. Let's face it, these migrations are typically neither fun or easy. Luckily, we’ll discuss how you can help change that.

 

Now, over the years, I have performed countless Orion Platform upgrades and migrations. And I, like many of you, have amassed a tremendous treasure trove of tips and tricks for streamlining the process down to an art form. The name of the game here is called downtime, and the less of it you can incur during your migration the sooner you get to go home, and the more you look like a rock star to your boss. What I'm about to show you here is how you can migrate your Orion Platform server with zero downtime!

 

As I stated above, there is a wealth of information on the subject of migrating the Orion Platform to a new server, and perhaps I overstated it a bit when I suggested that you're doing it wrong. There are multiple different (yet still correct) ways of migrating the Orion Platform from one server to another, and some ways may be faster, easier, or less error prone than others. These migrations typically vary depending upon the type of Orion server role the machine is hosting. This blog post focuses on the main Orion server, but the strategy can apply equally to Additional Polling Engines.

 

Orion Server Migration Made Easy

 

Going forward I'll assume you have at least one Orion server running NPM 12.0.1 or later—that one server being the main Orion server itself. If you're still running NPM 11.5.x, then chances are good you're not planning to migrate directly to Server 2016 or Server 2019 anyway, since 11.5.x isn't supported on either of those operating systems. I'm also going to assume that your Orion Platform server is currently running on Server 2012 or 2012 R2, though this process is equally applicable to those still rocking Server 2008 or Server 2008 R2. I'm also going to assume you have another freshly installed server ready for your Orion Platform migration. Lastly, this document won't be covering database server migrations. If that's what you were hoping for, there's an excellent document on the subject here.

 

First Things First

As with any good do-it-yourself project, the first order of business is to throw out, or otherwise lose, the instructions. I'm going to be walking you through what I’ve found to be the simplest, fastest, least error-prone manner of migrating the Orion Platform to a new server with absolutely zero downtime. None of those other documents or videos referenced above are going to show you how to do that, so let's just pretend they never existed.

 

Schedule Your Maintenance Window

While the Orion server should not be going down during the migration, it's always best to plan for the worst and hope for the best. I don't want anyone telling their boss that they decided to migrate their Orion server in the middle of the day because some guy on THWACK® named aLTeReGo told them to do it.

 

Backup Your Orion Server

Conventional wisdom would tell you that if it can go wrong, it probably will—so be prepared. If your Orion server is running on a virtual machine, take a snapshot prior to the migration just in case. While we won't be messing with that server at all during the migration, it's always good to have a safety net just in case.

 

 

Backup Your Orion Database

I can't emphasize this enough. BACKUP YOUR DATABASE! Seriously, just do it. Not sure if the backup from last night completed successfully? Do another one. Everything important is in the database, and with a backup, you can restore from virtually any disaster. If the database is corrupted though and you don't have a good backup to restore from, you may be rebuilding your Orion Platform again from scratch. You don't need to shut down the Orion Platform to take a backup, so go ahead and take another just to be on the safe side. We'll wait.

 

Need a little extra insurance? Why not give SolarWinds cloud-based server backup a try?

 

 

Do Not Upgrade (Yet)

If you’re migrating as part of an upgrade, don't upgrade yet unless you’ll be migrating to Windows Server 2019. It's best to leave the original server fully intact/as-is in the event something goes wrong and you need to roll back. There will be plenty of time to upgrade and play with all the cool new features later. For now, just focus.

 

 

Have Faith and Take a Deep Breath

This is going to start off a bit odd, but stick with me and we'll all come out of this together. Start by going to [Settings > All Settings > High Availability Deployment Summary] in the Orion web interface from a web browser on the new machine where you plan to migrate the Orion Platform. Next, click [Setup a New HA Server > Get Started Settings Up a Server > Download Installer Now].

 

Download the High Availability Secondary Server Installer

 

 

That's right, we'll be using the power of Orion High Availability (HA) to perform this Orion server migration. If at this point you're worried that you can't take advantage of this awesome migration method because you don't own an Orion High Availability license, fret not. Every Orion Platform installation comes with a full 30-day evaluation of High Availability for use on an unlimited number of servers. That's more than enough time for us to complete this migration! If you have no need for Orion High Availability, don't worry. The final steps in this migration process include disabling High Availability, so there's no requirement to purchase anything. However, you might find yourself so smitten with Orion High Availability by the end of the migration that you may wonder how you ever managed to live without it. You've been warned!

 

Begin Installation On Your New Orion Server

Once downloaded, double-click on the Scalability Engines Installer. Depending on which version of the Orion Platform you're running, the Scalability Engines Installer may look significantly different, so I've included screenshots below from both versions. On the top row, you’ll see screenshots from the Scalability Engines Installer version 1.x and version 2.x below that. Regardless of which version you're running through, the end result should be identical.

 

Connect to Existing Orion Server on Original Server

Select Server Role to Install

 

Once the installation is complete, the installer will walk you through the Configuration Wizard process. Ensure that all settings entered in the Configuration Wizard are identical to those used by your existing Orion server.

 

Let The Fun Begin

 

Now that we've installed a secondary Orion server, it's time to join them together into a pool (aka cluster). To do this, we begin by logging into the Orion web interface on your original Orion server. From there go to [Settings -> All Settings -> High Availability Deployment Summary]. There, you should find listed your original Orion server that you're logged into now, as well as your new Orion server that you just installed in the steps above. Click the “Set up High Availability Pool” button next to the name of your new Orion server.

 

Now, if both your existing Orion server and the new server you'll be migrating to are located on the same subnet, you might be prompted to enter different information within the HA Pool creation wizard. It's also important to note that if you're currently running Orion Platform 2017.1 or earlier, it will not be possible to perform this zero-downtime server migration, unless both your existing and new Orion servers are located on the same subnet.

 

Same Subnet Migration

 

If both your existing and new Orion servers reside on the same subnet, you’ll be prompted to provide a new, unused IP address on the same subnet as your existing Orion server. This virtual IP (VIP) will be shared between these two Orion servers, as long as they remain in the same HA Pool. The purpose of the VIP is to route traffic to whichever member in the pool is active. If you don't have intentions of keeping HA running after the migration, this IP address will be used only briefly and can be reclaimed at the conclusion of the migration. When you're done entering the IP address, click “Next”.

 

Migrating to Server in Different Subnet

 

If you're migrating to an Orion server on a different subnet than your existing one, then the HA Pool creation wizard will prompt you to provide a virtual hostname rather than a virtual IP address. This name helps ensure users are directed to the “active” member in an HA pool when accessing the Orion web interface whenever failovers occur. If you don't have intentions of keeping HA running after the migration, you can enter anything you like into this field. Once you've populated the “Virtual Host Name” field, click “Next.”

Close

On the “DNS Settings” step of the HA Pool creation wizard, select your DNS server type or choose “other” from the “DNS Type” drop-down menu if you don't intend on keeping HA running after the migration. If you choose “other,” you can populate any IP address and any DNS zone (even one that doesn't exist) into the fields provided—these values will not be used unless you plan to integrate Orion High Availability with a non-Microsoft and non-BIND DNS server in the future.

 

When complete, click “Next” to proceed, review the “Summary,” and click the “Create Pool” button to complete the HA Pool creation process.

 

Ready, Set, Cut-over!

 

From the Orion Deployment Summary [Settings > All Settings > High Availability Deployment Summary], select the HA pool you just created. On the right side, click the “Commands” drop-down menu and select “Force Failover.” This should initiate an immediate failover from your old Orion server to your new one. Note that while the cutover time for polling and alerting is typically just a couple of seconds, it may take the Orion web interface a minute or so before it's fully accessible. Unless you were accessing the Orion Web Console using the VIP you assigned earlier, you’ll need to change the URL in your browser to point to the IP address of the new Orion server or the VIP to regain access to the Orion web interface once you've initiated the failover.

 

Fore Failover.png

Verify you're cut over to the new server by looking at the pool members listed on the Orion Deployment Summary, specifically their state or roll showed just below their names. Your old Orion server should be listed as “Standby,” and your new Orion server should display as “Active.” Congratulations! You've just completed a successful Orion server migration with zero downtime!

 

Clean-up

 

The following steps should be completed within 30 days if you don't currently own or have plans to purchase Orion High Availability to provide continuous monitoring, redundancy, and near-instantaneous failover of your Orion server in the event of a failure. Don't forget that Orion High Availability also helps you maintain that your Orion Platform’s 100% uptime every month when Patch Tuesday rolls around. (Patch Tuesday… or, you know, when Microsoft releases its latest round of operating system hotfixes, all of which inevitably require a reboot.)

 

Shutdown Old Server

 

You should start the cleanup process by shutting down your original Orion server. It served you well, and we all know how hard it is to bid a final farewell to such a loyal friend, but its time has come. If you're not immediately planning to destroy the virtual machine or de-rack your old Orion server, you may first want to consider changing its IP address if you plan to use it on your new Orion server. This will ensure that if the old Orion server is started back up, it won't cause an IP address conflict and wreak havoc on your network monitoring. Once you've changed the IP address, resume with shutting down the server before proceeding with the next steps.

 

 

Remove The Pool

 

From within the Orion web interface, navigate back to the High Availability Deployment Summary by going to [Settings > All Settings > High Availability Deployment Summary]. Click on the name of the Pool you created earlier in the steps above. From the “Commands” drop-down menu on the right select “Remove Pool.”

 

 

Reclaim The Original Orion Server's IP Address

 

Last, but certainly not least, you may want to reclaim the IP address of your original Orion server by assigning it to your new Orion server. This is simply a matter of logging into the Windows server via RDP (or etc.) and opening the Network Control Panel. I prefer to go to the “Run” command and typing “ncpa.cpl” and <Enter> to open the Network Control Panel without needing to navigate around Windows. Once you've opened the Network Control Panel, right-click on your network interface and select “Properties.” Within the interface properties, select “Internet Protocol Version 4 (TCP/IPv4)” and click “Properties.”

 

Network Control PanelInterface Properties

 

Update the “IP Address” field by entering the IP of your original Orion server, then click “Advanced.” In the “Advanced TCP/IP Settings,” you’ll find the Virtual IP Address you configured earlier in the steps above—you should be able to safely remove this now. To do so, simply select it by clicking on the IP address with your mouse and then click the “Remove” button. Then, click “OK” on each of the three windows to save your changes.

 

TCP/IP PropertiesAdvanced TCP/IP Settings

 

Update DNS/Machine Name

 

Do not rename the server itself in Windows. If you have users who are accessing the Orion Web Console via the original server’s name, the best and easiest method of ensuring those users can now access the new server is to create a DNS C-Name that points to the new server. It's always a good idea to have a layer of abstraction between what name end users type into their browser and the name of the server itself. This can help ensure that you can easily redirect those users later, should you want to add an Additional Web Server or re-enable High Availability. To accomplish this, we are going to create a DNS CNAME record for your original Orion server's name that points to the new Orion server. In this example, I'm using Windows DNS, but the same principle applies for really any type of DNS server.

 

From the DNS Control Panel on your DNS Server, expand “Forward Lookup Zones” and right-click on your domain name and select “New Alias (CNAME).” In my example below, my previous server's FQDN (Fully qualified domain name) was “solarwinds.sw.local” and my new Orion's server name is “pm-aus-jmor-04.sw.local.” In the “Alias name” enter “solarwinds.” The “Fully qualified domain name” field will automatically populate with the alias and domain name. In the “Fully qualified domain name (FQDN) for target host” field, enter the FQDN of your new Orion server and click “OK” to save your changes. Lastly, find and delete the ANAME “Host (A)” record for your old Orion server.

 

DNS Control PanelAdd New Alias (CNAME)

 

While this undoubtedly looks like a lot of steps, the process is actually fairly straightforward and I completed it in less than an hour. Now, obviously your mileage may vary, but regardless of how long it may take, there's no simpler way—for which I'm aware—that will allow you to migrate your Orion Platform to a new server with anywhere close to zero downtime. Hopefully, this process will save you a fair bit of time and frustration over the previous methods referenced above. If you have any tips and tricks of your own that have simplified your Orion server migrations, feel free to post them in the comments sections below—we'd love to hear them!

 

The SolarWinds trademarks, service marks, and logos are the exclusive property of SolarWinds Worldwide, LLC or its affiliates.  All other trademarks are the property of their respective owners.

No, you haven't entered a multidimensional time warp. Nor are you having a 90's flashback. While the industry hype cycle is primarily focused on hot new trends like hybrid IT, SaaS, and containers, there lurks an unsung hero in the darkest dwellings of many of today's most established organizations. It oftentimes doesn't get the attention or appreciation it deserves, because to most, its existence is completely transparent. It sits there in the corner, just plugging away, day after day, hour after countless hour, without complaint or need for recognition. Yet these systems remain at the very core of the business, handling the most critical transactions. From maintaining patients medical records, keeping all your banking transactions in order, to running some of today's largest companies CRM and ERP applications, AIX is still very much around us every day, touching our lives in ways you probably haven't even considered.

 

For as important as these systems remain even today, the monitoring of their performance and application health is far too often overlooked or completely forgotten. Perhaps it's because these workhorses were built to last and seldom fail at their important duties, making them fall into the dangerous category of out-of-sight-out-of-mind. More likely, however, is that these systems have traditionally been extremely difficult to gain visibility into using modern day multi-vendor monitoring solutions. That may be because a long time ago, IBM seemingly stole a page out of Sony's playbook of market dominance, which had propelled their proprietary Betamax and MiniDisk formats into the iPhone like successes of their day. Oh, wait. That's not what happened! That's not what happened at all!!

 

Unfortunately, despite strict and very well defined industry standards which would govern how key operating system metrics should be exposed, and allowing third-party monitoring solutions to provide necessary insight into their health and performance, IBM decided that standards didn't necessarily apply to them. This decision has historically made monitoring AIX systems challenging for both their customers, as well as, 3rd parties seeking to provide a monitoring solution for those organizations most critical systems. Compounding this problem is the fact that the few monitoring solutions available to those customers have traditionally been wildly complex, difficult to deploy and configure, and even more challenging to maintain.  A new solution was needed. One which could bring with it unexpected simplicity, where none existed before. Its time has come, and that time is now.

 

 

AIX Agent Deployment

 

As one would expect from SolarWinds, deployment of the AIX agent is a simple turnkey affair, no different than deploying Agents to other operating systems, such as Windows or Linux. That's right, deploying an Agent to AIX is just as simple as it is for Windows and you don't need to be an expert in AIX. In fact, you don't even need any experience using AIX to be successful monitoring these systems with Server & Application Monitor (SAM) 6.6. If you can add a Node in Orion, then you, too, can monitor your AIX 7.1 and 7.2 systems.

 

Add Node Wizard - Push Deployment

 

To begin, navigate to [Settings -> All Settings -> Add Node], enter the IP address or fully qualified hostname of the AIX host you'd like managed in the "Polling Hostname or IP Address" field and select the "Windows & Unix/Linux Servers: Agent" radio button from the available "Polling Method" options. Next, enter the credentials that will be used to both connect to the AIX host and install the agent software on the 'Unix/Linux tab. The credentials provided here should have 'root' or equivalent level permissions. Note that the credentials provided here are used only for initial deployment of the agent. Future password changes of the account credentials provided here will have no impact on the agent once it is deployed. Alternatively, if you authenticate to your AIX host via SSH using a client certificate rather than a username and password, click the 'Certificate Credential' radio button and upload your certificate in PEM format through the Orion web interface. This certificate will then be used to authenticate to the AIX host for the purpose of installing the Agent.

 

You can also optionally add SNMP credentials to the Agent if SNMP has already been configured properly on the AIX system. Rest assured, though, that this isn't needed and is used only if you're wanting to utilize SAM's SNMP Component Monitors against the AIX system. Configuring this option will also populate the 'Location' and 'Contact' fields located on the 'Node Details' resource if those values have been properly populated in your SNMP configuration. Everything else will be polled natively through the AIX Agent with zero reliance upon SNMP.

 

 

Once you've entered your AIX credentials, click the 'Next' button at the bottom of the page. The Agent will then be deployed to the AIX host using a combination of SSH and SFTP requiring TCP port 22 be open from the Orion server (or additional polling engine) to the AIX endpoint you wish to manage for push deployment to function properly.

 

Install Agent PromptInstall Agent Progress IndicatorList Resources

 

Manual - Pull Deployment

 

In some scenarios, it may not be possible for the Orion server to push the agent to the AIX host over SSH. This is not uncommon when the host you wish to manage resides behind a NAT or access control lists restrict access to the AIX system via SSH from the network segment where the Orion server resides.  While firewall policy changes, port forwarding, or one-to-one address translations could be made to facilitate push deployment of the agent, in many cases, it may be far easier to perform a manual deployment of the agent to those hosts.

 

The Agent package can be downloaded from the Orion web interface to the AIX host by going to [Settings -> All Settings -> Agent Settings -> Download Agent Software] and selecting "Unix/Linux" from the options provided and clicking "Next".

 

Download Agent Software - Machine Type
Download Agent Software - Deployment Method

 

In the following step of the Wizard select "Manual Install" and click "Next". Finally, in the third and final step of the wizard is where you will select 'IBM AIX 7.x' from the 'Distribution' drop down. Here you can also configure any advanced options the agent will use when it is installed, such as which polling engine the Agent should be associated with in Agent Initiated (Active) mode, or the listening port the Agent will use when running in Server Initiated (Passive) mode. Additionally, you can also specify a proxy server the Agent should use to communicate to the Orion server or Additional Polling Engine in Agent Initiated (Active) mode. If you're deploying in an environment where proxy servers are used, fret not. The Agent's proxy configuration fully supports the use of authenticated proxies.

 

 

After selecting all the appropriate configuration options, click the "Generate Command" button at the bottom of the page. This will generate a dynamic installation command based upon the settings chosen above, which can then be copied and pasted into an SSH or X-Windows session on the AIX host. The AIX machine will then download and install the appropriate agent software from the Orion server using those pre-configured options.

 

Copy Generated Agent Installation CommandPaste Command into SSH TerminalAgent Installation Success

 

As soon as the Agent is registered with the Orion server, select your newly added agent node and click "Choose Resources" from the 'Manage Agents' view to select items on the node you would like to monitor.

 

 

Agent Advantages

 

So what's so great about Agents anyway? What's wrong with using the tried and true agentless methods for monitoring AIX hosts, like SNMP?

 

Encryption

 

Well, as anyone who has the misfortune of using SNMP to monitor their AIX hosts can tell you, it's not all sunshine and lollipops, starting with configuring SNMP. Most environments today have strict security standards which mandate the use of encryption for virtually all network communication. While configuring SNMP v1/v2 on AIX isn't especially difficult for an experienced AIX administrator, neither of those versions of SNMP utilizes encryption. That would necessitate that users utilize SNMPv3, which comparatively speaking, practically requires users obtain a Ph.D. from Big Blue University in AIX to properly enable and configure.  By comparison, the Orion AIX Agent natively utilizes highly secure 2048 bit TLS encryption for all network communication.

 

Visibility

 

IBM's proprietary SNMP daemon leaves much to be desired when compared to other standard based SNMP daemons running on alternative operating systems. Chief among the complaints I hear regularly is that IBM's SNMP daemon doesn't support important standard MIBs, such as the HOST-RESOURCES-MIB which exposes key pieces of information regarding running processes on the server and their respective resource consumption. This remains the primary reason why so many customers have chosen to replace IBM's proprietary SNMP daemon with NET-SNMP.  SImilar to NET-SNMP, though, are issues of reflecting critical metrics accurately, such as memory utilization. It seems odd that something so basic would present so many challenges and be pervasive across both Linux and AIX when monitored via SNMP.

 

Reliability

 

Like all Agents in Orion, the AIX Agent runs independently of the Orion server. This means the Agent continues to monitor the host where it's installed, even if the Orion server is down, or otherwise inaccessible due to a network outage. Once connectivity is restored or the Orion server is brought back online, the data collected by the AIX agent is then uploaded to the Orion server, filling gaps in the historical time series charts that would have otherwise existed if that node was being monitored via SNMP. This ensures that availability reporting is accurate, even if the server running Orion experiences a catastrophic failure.

 

Reachability

 

In today's highly secure and heavily firewalled environments which are riddled with network obstacles such as network address translation, port address translation, access control lists, and proxies, it's sometimes amazing that anything works at all. More and more the things that need to be monitored are oftentimes the most difficult to monitor. With the AIX agent, overcoming these obstacles is a snap, allowing users to monitor their AIX systems regardless of where they might be located in the environment. Have your Orion system deployed in the Cloud and running in Amazon's AWS or Microsoft's Azure? Not a problem. Deploy the Agent in Agent Initiated (Active) Mode and forget about VPN tunnels or 1:1 NAT mappings. Does all traffic leaving the network go through a proxy server? No problem. The Agent natively supports the use of authenticated proxies to access the Orion server, while conversely, Agent communication within Orion can be configured to utilize a proxy server to reach an Agent that might not be accessed directly. These are possibilities you previously could only dream about when using SNMP.

 

 

AIX Agent Exclusive Features

 

There have been several Orion features released throughout the years which had previously only been available for nodes running other operating systems, such as Linux or Windows. AIX had largely been left out in the cold. That is, until today.

 

Network Interface Monitoring

 

In Server & Application Monitor 6.6, network interfaces on your AIX server can now be monitored without needing Network Performance Monitor installed. This functionality is available exclusively through the AIX Agent and does not count against your SAM component monitor usage or NPM element license count, in the event you also have NPM installed. That means this functionality is provided essentially free and potentially even allows you to free up some of those valuable NPM element licenses for other nodes in your environment.

 

Volume Performance Monitoring

 

Today, storage is the leading cause of server and application performance issues. Having visibility into storage volume performance, such as disk reads/writes per second, and queued disk I/O from within the Orion web console alongside other key performance indicators, allows you to isolate where performance bottlenecks are occurring on your server and which applications are affected. With the AIX Agent, you now have visibility into the storage volume performance, similar to those that you've grown accustomed to on your Windows and Linux volumes.

Total Disk IOPSDisk Queue Length

 

 

Real-Time Process Explorer

 

When applications aren't running right, inevitably there's a culprit. It may be the processes that make up the application you're already monitoring, or it might be with those you aren't. The Real-Time process explorer provides you visibility into all processes and daemons running on your AIX server, along with their respective resource utilization. It's like your web-based command center where you can quickly determine which processes are running amuck. No more firing up your SSH client, logging in and running 'topas' to troubleshoot application issues. Now you can do it all from the comfort of your web browser. Spot a runaway process or one that's leaking memory like a sieve? You can also terminate those processes directly within that same web interface. Simply select the process(s) you want to 'kill' and click 'End Process'. Voila! It's just that easy.

 

You can also now select processes you wish to monitor on your AIX server directly through the Real-TIme Process Explorer. To do so, simply select the process you're interested in monitoring and click 'Start Monitoring'. You'll then be walked through SAM's application template wizard where you can choose to add this process to one of your existing Application Templates or create a new one.

 

 

 

Reboot Management Action

 

If you find yourself in a situation where terminating processes alone does not resolve your application issue, there's always the tried and true reboot. While usually the option of absolute last resort, it's comforting to have it easily at hand when and if you've exhausted all other options. Simply click the 'Reboot' button in the 'Management' resource on the 'Node Details' view and you'll be prompted to confirm that you really mean business.

 

 

Application Component Monitors

 

Last, and unquestionably most important, are the wide array of various SAM Application Component Monitors supported by the AIX Agent. From these components, you can create templates to monitor virtually any application, commercial, open source, or homegrown.

 

AIX Agent Supported SAM Component Monitor Types

Directory Size Monitor

File Count Monitor

HTTPS Monitor

ODBC User Experience Monitor

DNS User Experience Monitor

File Existence Monitor

JMX Component Monitor

Process Monitor

File Age Monitor

File Size Monitor

Linux/Unix Script Monitor

SOAP Monitor

File Change MonitorHTTP MonitorNagios Script Monitor

SNMP Component Monitor

TCP Port Monitor

Tomcat Server Monitor

Orion and the modules which run atop the platform provide a tremendous wealth of statistical information at your fingertips for spotting trends and hotspots. That data collected is also helpful for determining if what you're seeing now is anomalous, or normal consistent behavior based upon historical analysis. Unfortunately, one area where Orion hasn't been quite as strong is helping users troubleshoot active ongoing issues. Should you find yourself in the throes a major outage or performance issue, Orion does an outstanding job of ensuring you're alerted to the problem at hand. Where it falls short however, is providing tools which aid in your ability to diagnose the root cause of the issue in real-time.

 

As many of you are keenly aware, default polling intervals for statistic data collection in Orion is typically somewhere between 5-10 minutes for most Orion product modules. While this normal polling interval for statistic collection is perfectly reasonable for trend analysis, alerting, and reporting, it's less than ideal when you're actively troubleshooting an ongoing issue. Ideally, you'd want the ability to make change, like restarting a Windows service or Linux daemon, change a CBQoS policy, or allocate additional resources to a virtual machine, and then see immediately the impact those changes are having to the issue you're trying to resolve. In these situations, it's simply untenable to wait 5-10 minutes for Orion's next polling cycle to determine if what changes you made resolved the issue. Doing so significantly bottlenecks the number of things you can try, and extends the duration of the outage as you wait for Orion's next scheduled polling interval to determine if the issue is resolved.

 

Sure, there are alternatives and workarounds which many people leverage in these situations. Some choose to click the 'Poll Now' button feverishly to get updated values ahead of the normal 5-10 minute polling interval, but even this takes a minute or so before data is collected and visible within the Orion web interface. While better, this is still less than optimal for troubleshooting purposes. Others instead, use different tools like command line interfaces on switches, routers and linux, or Resource Monitor and Task Manager on WIndows for their firefighting needs. These tools though, have their own drawbacks, such as requiring you leave Orion where you were initially alerted to the problem, and console into the device exhibiting the issue. If this problem potentially spans multiple devices, such as in the case of distributed application architectures, clustered or load balanced servers, HSRP, VRRP, etc. then you'll be forced to juggle multiple console sessions with no ability to compare or correlate metrics between devices.

 

 

Enter PerfStack

 

With the release of PerfStack included in Orion Platform 2017.3, these woes are a thing of the past. No more juggling between different tools as your boss watches over your shoulder, breathing down your neck as you scramble to isolate the cause of your next critical performance issue. With our new improvements to PerfStack, we introduce you to real-time polling, which provides up to one second statistic collection granularity when activated. This can be for a single entity like a node, or even multiple disparate entities simultaneously.

 

PerfStack-Real-Time-Polling.gif

 

 

Start Real-Time Polling

To begin using PerfStack's new Real-Time Polling capabilities, start a new project and add a node by clicking 'Add Entities'. Expand the 'Node' category and click on the node you just added in the previous step to select it. This will populate the metric pallet with the list of all available metrics for that entity. Within the metric palette, expand 'CPU/Memory' or 'Response Time' and you will notice a blue rocketship icon which adorns many of the available metrics listed. This icon denotes that the metric is available for Real-Time Polling. Note that not all metrics for a given entity are pollable in real-time. A full listing of all real-time pollable metrics can be found by expanding the 'Real-Time Polling' category in the metric palette of the selected entity.

 

Rocket Ship.pngReal-Time Polling Category.png

 

Once you've identified which real-time metrics you'd like to visualize within your PerfStack project, drag and drop those metric tiles into the chart area the same as you would any other metric. You can of course include both real-time and non-real-time metrics within the same project, but only those denoted with the blue rocket ship icon will be updated within the chart at one second intervals. Other metrics included within the same project will continue to update themselves based upon their normal scheduled polling intervals.

 

Now that you've added the some real-time metrics to your PerfStack project, simply click the 'Start Real-Time Polling' icon in the top action bar. This will automatically change the timeframe of the chart to the last 10 minutes. This allows you to more easily visualize variations in the charted values at high frequency polling intervals. You may also notice the rocketships blink when real-time polling is starting. This process takes just a second or two, then the charts begin to move. To stop real-time polling, simply click the 'Stop Real-Time Polling" button in the top action bar.

 

 

Start-Real-Time-Polling.gif

 

 

Real-Time Polling Limits

While real-time polling is active, you can continue to add or remove additional real-time metrics to your project. These can be from the same, or entirely different entities. Real-Time polling will continue for those existing metrics on the chart, and any newly added metrics will begin to update in real-time. There is a limit of ten unique real-time metrics per-project which can be polled. Should you exceed this limit, you will notice a toast message appears in the top right of the window when attempting to add the eleventh metric to a chart where real-time polling is enabled. This same message will appear if your project contains more than 10 real-time pollable metrics and you attempt to enable Real-Time Polling. To resume real-time polling, reduce the number of metrics which can be polled in real-time within your PerfStack project to ten or fewer.

 

Session LimitGlobal Limit
PerfStack RealTime Exceeded.pngPerfStack Real-Time Global Limit.png

 

In addition to the per-session limit of 10 real-time metrics, there is also a notification if you exceed a global limit of thirty unique metrics across all web interface sessions on the Orion server. Real-time polling uses a shared cache across all sessions, so if you and three of your colleagues are viewing the same ten metrics in real-time within PerfStack this only counts as 10 real-time metrics, not 40. This is because PerfStack is only polling the device in real-time once, and not for each unique user session. This helps reduce overhead on the Orion server, as well as any strain on the monitored device.

 

Polling Methods

In our ever enduring commitment to remain an agentless first monitoring solution, Real-Time Polling in this release is available only for nodes managed via ICMP, SNMP, or WMI. Those nodes which are managed via the Orion Agent cannot as yet utilize Real-Time Polling. Should you select an entity within PerfStack that is managed via the Agent, you will notice the absence of any blue rocket ship icons in that entities metric tiles, denoting that Real-Time Polling is not available for that entity.

 

Metrics and Entities Supported

As stated above, Real-Time Polling is not yet available for all metrics and entity types. For this release of PerfStack, we focused on what we believe to be the most vital real-time metrics users would need at hand during a firefight. This includes 34 metrics spanning across three different entity types, nodes, interfaces, and volumes; allowing you to troubleshoot the most common network, storage, and device related performance issues in real-time from a single, centralized, web based interface. If you'd like to see additional real-time metrics supported in future releases, we'd love to know which ones you would find most valuable, and how you would plan to use them.

 

NodesInterfacesVolumes
Average CPU LoadAvailabilityAverage Disk Queue Length
Average Memory UsedReceived DiscardsAverage Disk Reads
Average Percent Memory UsedReceived ErrorsAverage Disk Transfer
Peak CPU LoadTransmit DiscardsAverage Disk Writes
Peak Memory UsedTransmit ErrorsMaximum Disk Queue Length
Minimum CPU UsedAverage Receive bpsMaximum Disk Reads
Minimum Memory UsedMinimum Receive bpsMaximum Disk Transfer
Average Response TimePeak Receive bpsMinimum Disk Queue Length
Maximum Response TimeReceive Percent UtilizationMinimum Disk Reads
Minimum Response TimeAverage Transmit bpsMinimum Disk Transfer
Minimum Transmit bpsMinimum Disk Writes
Peak Transmit bps
Transmit Percent Utilization

 

 

User Restrictions

We at SolarWinds, understand that not all Orion administrators may want every user to have access to such an amazing feature. After all, they may be completely mesmerized by the screen and not get any actual work done as a result. With that in mind, you will find a new user or group level permission which controls whether the 'Real-Time Polling' button appears within PerfStack for those users. This new setting can be found under [Settings -> All Settings -> Manage Accounts]. From there, select a group or individual user account and click 'Edit'. Expand 'Performance AnalysIs Settings' at the bottom of the page and change this setting from 'Allow' to "Disallow' for any user or group. This will disable Real-Time Polling for those users. By default, all users have permission to launch Real-Time Polling within PerfStack.

 

Real-Time Polling is only one of the latest improvements we've made to PerfStack in the Orion Platform 2017.3 release. If you're interested in what other goodies we've stuffed under the hood, hop on over to my earlier post, entitled Orion Platform 2017.3 - PerfStack New Features & Improvements for the full rundown.

 

 

Syslog

When PerfStack was initially released, a surprising few key metrics were noticeably absent. Chief among those, was the surprising lack of Syslog data. In the Network Performance Monitor 12.2 release, and all Orion product modules which include Orion Platform 2017.3, we rectified this injustice, bringing Syslog into the PerfStack fold. For any node sending Syslog data to Orion you will find a new 'Syslog' metric tile under the 'Status, Events, Alerts' category. Simply drag that tile to the chart area, and voila! Syslog data charted over time broken down by severity level.  As with all metric tiles within PerfStack this metric tile is dynamic and will only appear Nodes which have been configured to send Syslog data to the Orion server. If this tile does not appear for nodes you believe should, verify that Orion has received Syslog data from the device using the web based syslog viewer within the Orion web interface.

 

 

Hovering your mouse over the charted area will show the total number of syslog messages received at the top of the legend for the time shown below the vertical marker, as well as a breakdown of each severity type contributing to that total beneath it.

 

 

SNMP Traps

Not to be outdone, the inclusion of SNMP Trap data has also been added. Much like Syslog, SNMP Trap data is broken out by severity and is available as a dynamic metric tile for any node which is configured to send SNMP Trap data to Orion. The SNMP Trap metric tile can be found under the same 'Status, Events, Alerts' category as Syslog, when a node is selected from within the metric palette.  If this tile does not appear for nodes you have configured to send SNMP Trap data to Orion, verify that Orion is receiving those SNMP Traps from the device using the web based SNMP Trap viewer, accessible from within the Orion web interface.

 

 

 

Zoom

When hovering your mouse over the charted area you may notice your mouse cursor has learned a new trick, changing to crosshairs. Holding down your mouse button while dragging across the charted area allows you to lasso a specific time period of interest, such as a sudden spike in resource usage. The selected area is then the focal point of your project, while the rest of the chart area surrounding this time period becomes visually de-emphasized through color desaturation. while the colors remain bright and vibrant within the selected area.  This easily allows you to focus your attention on the area selected area without visual distraction from the surrounding area. This selection process occurs across all charts within the PerfStack, making it easier to visually correlate what else occurred during the same time period.

 

 

Once a time period has been selected, new options appear next to the selected area. Clicking the [+] icon highlighted above, zooms into the selected time range where you can view high fidelity detailed data collected during that time period. Similarly, clicking the [-] icon allows you to zoom further out to spot trends, or return to your previous perspective after having zoomed in. Any time after having made a selection, clicking the [X] icon will cancel the selection and return focus to the entire viewable chart area.

 

 

Data Explorer

Great! So now you know how many Syslog messages and SNMP Traps were received from any of your devices, along with their respective severity. You can even zoom into a specific time frame and cross correlate this data against other metrics from the same or different entities monitored by Orion. That's some super powerful stuff! But you know what would make this data even more powerful?

 

What if you could actually view the full details of those Syslog or SNMP-Traps from within PerfStack itself? That would assuredly accelerate the troubleshooting process and aid in reducing time-to-resolution; both of which are key tenets of PerfStack. Well that's exactly what we've done!

 

To get started, select a time period in the chart area, the same as described above to zoom in or out of the chart. Next, click the top paper & magnifying glass icon from the options displayed to the right of the selected area. This action will cause the Data Explorer tab to be shown in the left pane, where the Metric Palette normally appears. Switching between the Data Explorer and the Metric Palette is simply a matter of clicking on the appropriate tab.

 

Within the Data Explorer, all Syslog or SNMP Trap data is listed in the chronological order it was received. Each line represents a single message, beginning with its severity and ending with the date and time the message was received. In between is a brief preview of the message body. To view the full message text, simply expand the row.

 

 

If your devices are sending a lot of Syslog or SNMP Traps to Orion, it may be difficult to sift through all the noise and focus on what's truly important, even if you select the tiniest window of time. Since this just so happens to be another key tenet of PerfStack, we added filtering and search to the Data Explorer. This allows you to do things, such as show only Warning or Critical messages that were received during the selected time period, while filtering out the excessive noise generated by Informational and Debug messages.

 

And BOOM! Just like that, the problem is found. If SolarWinds was a leading US based office supply company, right now you'd probably feel compelled to blurt out 'That was easy". The magic doesn't end there either. This same functionality that's available for both Syslog and SNMP Traps can also be used to view the details of Orion Events. So if you aren't afforded the opportunity to configure devices to send Syslog or SNMP Traps to your Orion server, you can still give this new feature a whirl by adding Orion Events to your PerfStack and following the instructions outlined above.

 

 

Additional Metrics Support

In addition to Syslog & Traps, PerfStack in Orion Platform 2017.3 includes support for a variety of additional Orion product module metrics in this release. Given the feedback we have received since the initial release PerfStack, we know these will all be extremely welcomed additions.

 

Universal Device Pollers

That's right, I said Universal Device Pollers! Unquestionably the single most often requested feature request I receive for PerfStack has been adding support for Universal Device Pollers. With the release, I'm proud to announce you can now add Universal Device Pollers to your PerfStack projects no differently than any other metric. Universal Device Pollers for both Nodes and Interfaces are supported, and appear under their respective entity type. When you select an interface for example, which has Universal Device Pollers assigned, the 'Group' names as defined within the Universal Device Poller Windows application will appear within PerfStack as new metric categories. In the example below I have a Universal Device Poller Group I've defined in the Win32 application called 'Cisco Switch', which I've assigned to interface 'Fa0/1' on 'lab-transi-sw1'. Similarly, I have a Node based Universal Device Poller called 'sonic Current CPU Util' which is assigned to 'stp-nsa2400'. Please note that for Universal Device Pollers to appear in PerfStack, they must be of type 'Rate' or 'Counter' and that 'Keep Historical Data' must be enabled.

 

PerfStack Universal Device Pollers.png

Network Insight for F5 & ASA

This release of PerfStack also includes support for NPM's Network Insight for F5, and all new Network Insight for ASA. These metrics appear under their own distinct categories or node entities and are treated no differently than any other metric within PerfStack.

 

F5 ASA.png

 

Voice & Network Quality Manager

A party just isn't a party unless you invite your friends, so in this release we invited VNQM to join the fun by bring metrics for IPSLA operations into PerfStack. IPSLA Operations appear as their own separate entity type within PerfStack. If however, you find it easier to search by source router instead you can select that node entity and click the add related items button and all IPSLA operations running on that router will appear listed in the entities list. Select the IPSLA operation you'd like to see more information about and the list of all available metrics for that operation appear listed in the metric pallet. From there you know the drill; just drag and drop them onto the chart area and voila!

 

Network Configuration Manager

Also joining the party is NCM, allowing Orion users for the first time ever to visually cross correlate configuration changes to the impact they have on the network. When combined with NTA you can easily see the effect your recent CBQoS policy change is having on the flow of traffic from the moment the change was made. PerfStack also makes it easy for you to not only determine exactly when a change was made, but by whom. Similar to Syslog, Traps, and Events, selecting a time period from the charted area and clicking the Data Explorer button reveals detailed information about the configuration change that occurred, such as the username of the individual who logged into the device and their IP address.

 

 

 

 

Alert Visualization

Visualization of alerts in the premiere release of PerfStack displayed only the total aggregate of all alerts against a given entity, as well as how long all alerts had been active against that object. While useful, you were unable to determine what those alerts were which triggered, or how long each of those alerts remained active. A lot of that important detail was obscured through aggregation, making this particular area of PerfStack ripe for improvement.

 

In this release of PerfStack we preserved the same total alert aggregate that was available in the first release, but then extended the chart to show the names of the alerts which triggered along with their individual durations. No longer are you left wondering what alert was triggered against the object, or fumbling through other areas of the Orion web interface to track down that information. You'll also know at a glance when the alert triggered and for how long, in a manner which allows you to visually recognize patterns of reoccurrence and correlate specific individual alerts against other metrics collected by Orion.

 

Export

Occasionally it's necessary to share your PerfStack findings with others who may not have access to Orion, or archive those findings in a ticketing system for historical purposes beyond your defined retention period. For some, this information needs to be imported into other systems for charge back, show back, billing, forensic analysis, or correlation with other non-Orion tools in the environment. Previously, your only recourse was to export data for each metric individually via the Custom Chart View, or write your own series of custom queries against the SQL database backend to obtain the raw values behind these charts.  In this PerfStack release however, those days are behind us.

 

After adding all metrics of interest to your PerfStack project, simply click the new 'Export' button located in the top menu. This will export your project's content to a Microsoft® Excel friendly comma separated value (CSV) formatted file,which is then downloaded to your local machine via your browser.

 

Double click the file to open in Excel, or upload the file to Google™ Docs to open in Sheets. Inside you will find all the raw data which made up the charts in PerfStack. Each series of the same chart is represented as its own set of columns, complete with the entity and metric name, date and time the data was collected, and its value. If your PerfStack project contained multiple charts, the values for each chart are grouped together in the CSV file the same as they were visually laid out within PerfStack itself. Simply put, the detailed raw data for the second PerfStack chart is directly beneath the end of the series for the first chart data contained within the CSV file.

 

 

The logical layout of the CSV file makes it easy to visually recreate similar charts to what was seen in PerfStack, using the native graphing tools included in Excel or Sheets. The format of the raw data is also well suited for import into 3rd party reporting solutions like Domo or eazyBI. With the data contained in logical layout and an open format, the possibilities are limitless.

 

 

 

Usability Improvements

 

Share

Not everyone who used PerfStack initially realized that whatever they created could be easily shared with others, simply by copying the URL and sending it to them. Since this is one of PerfStack's most powerful capabilities, we felt it needed to be promoted to the top menu, alongside other important functions like saving and loading a PerfStack.

 

Just click this 'Share' button and the dynamic PerfStack URL is automatically copied to your clipboard and ready to be pasted into an email, instant message, helpdesk ticket, etc. and shared with others.

 

Getting to PerfStack in previous releases meant leaving what you were looking at and starting the troubleshooting process over from the very beginning again in PerfStack if you needed to correlate symptoms with their root cause. For example, if users are complaining about the performance of SharePoint, a logical starting point might be to go to the Node Details view of the SharePoint server in Orion. But what if you then wanted information from the Hypervisor this virtual machine is running on, the storage array, or the SharePoint application being monitored by SAM? Well, you'd probably navigate to PerfStack, add the problem node, and then its relationships, before eventually plotting metrics in the chart area for correlation. This sounds tedious just explaining it and we knew we could do better.

 

Within the 'Management' or 'Details' resource located on the details view of virtually any entity type supported by PerfStack, you will find a new 'Performance Analysis' link. When pressed, you will be taken directly to PerfStack and the entity object you came into PerfStack will be pre-populated in the entity selector, along with any of its related items. In addition, the chart area will pre-populate with relevant metrics associated with the entity you came in from.

 

 

For example, if you were to click on the "Performance Analysis' link from the 'Node Details' view of your SharePoint server, you would be taken to PerfStack where the Node, it's volumes, interfaces, etc. are already listed in the entity list, and metrics such as Status, CPU/Memory utilization, response time, alerts, and events are all pre-populated for you. These metrics are dynamic based upon the entity type you enter from, ensuring they are always relevant to what you're investigating.

 

Links To PerfStack.png

We didn't stop simply at having links into PerfStack from other views in Orion. We knew that there were occasions when users viewing data in PerfStack needed additional information only found on entity details views, such as MAC addresses, serial/model numbers, etc.. WIth that in mind, we included direct links to the Details view of any entity shown within PerfStack's entity list. Simply hover your mouse over the entity name, the same as you would to add related items or to remove the entity from the list. There you will notice a new link icon, which when clicked will open a new browser tab that will take you to the details view for that entity.

 

Link to Details from PerfStack.png

 

Drag & Drop Entities

We all know you can drag and drop metrics onto PerfStack's chart area to visualize virtually any combination of metrics desirable, but what if I told you that you could drag and drop entire entities into the chart area? Would that blow your mind?  Well that's exactly what you can do now with PerfStack!

 

Utilizing the same logic derived from 'Links to PerfStack' referenced above, relevant and dynamic metrics associated with a given entity are pre-populated and charted when an entity is dragged into PerfStack's chart area. Simply click and hold your mouse on the drag handle which appears to the left of the entity name when hovering your mouse. Next, drag the entity into the chart area. This will then populate the charted area will the same metrics that would appear if you had entered PerfStack through the 'Performance Analysis' link on that entities Details view, saving you precious time in the throes of troubleshooting.

Drag and Drop Entities.png

Full Screen Mode

WIth the initial release of PerfStack we received a lot of feedback from customers wanting to add PerfStack to a wallboard in their NOC. The first issue these customers ran into was a bug where PerfStack did not respect session timeout values defined for the user account. I'm happy to announce that this issue has been resolved, allowing you to have PerfStack running and updating indefinitely if so desired, without ever timing out your session.

 

Next on their wish list was some ability to declutter the UI of extraneous elements which were unnecessary for a non-interactive display. This would allow them to maximize the viewable area for data being displayed in the charts and legend. Being the accommodating bunch that we are, a newly added button was added to the top right of PerfStack, just above the chart legend. When clicked, all UI elements except the chart and legend are removed, placing PerfStack into fullscreen mode. To exit full screen mode and return to normal mode, just click the button again or remove all metrics from the chart. Note that this button will only appear when one or more metrics are plotted in the chart area.

 

Maximize.png

 

Sharing is great when you're collaborating on a specific issue with a group of individuals, but what if you as the Orion Administrator want to create custom PerfStack dashboards to share with your users? This can be accomplished with other custom Orion views fairly easily, and PerfStack function no different.

 

To begin, first start by creating your custom PerfStack and including all metics you'd like represented in the chart. When complete, save your changes and click the 'Share' button. You should now have the URL to your saved PerfStack in your copy/paste buffer. Next, go to [Settings -> All Settings -> Customize Menu Bars] and edit the menu bar for the user/s you'd like to have access to your saved PerfStack. At the bottom of the page click the 'Add' button, give your link a name, and paste the saved PerfStack URL into the URL field of the 'Edit Custom menu Item' dialog windows that appears. From there, click 'ok' to save your changes and drag your newly created menu item from the 'Available Items' column to the 'Selected Items' column to add this to your menu bar.

 

When users which are assigned that Menu Bar login, they will now see a link to your custom saved PerfStack in their navigation. This allows Orion administrators to quickly share custom saved PerfStacks without emailing or instant messaging links to users. Similarly, you can now also use the 'User Links' resource in a similar fashion to provide your users links to custom saved PerfStack dashboards.

 

 

This represents an incredible amount of awesome jam packed into a single release, and I haven't even mentioned Real-Time polling yet! Let us know what your thoughts are these PerfStack improvements in the comments section below. We'd love to hear your feedback!

Hopefully you are already reaping the benefit from the many improvements that were made in Network Performance Monitor 12.1, Server & Application Monitor 6.4, Storage Resource Monitor 6.4, Virtualization Manager 7.1, Netflow Traffic Analyzer 4.2.2, and Network Configuration Manager 7.6. If you haven't yet had a chance to upgrade to these releases, I encourage you to do so at your earliest convenience, as there are a ton of exciting new features that you're missing out on.

 

Something a few who already upgraded may have seen, is one or more deprecation notices within the installer. These may have included reference to older Windows operating systems or Microsoft SQL versions. Note that these deprecation notices will only appear when upgrading to any of the product versions listed above, provided you are installing on any of the Windows OS or SQL versions deprecated in those releases. But what does it mean when a feature or software dependency has been deprecated? Does this mean it's no longer supported, or those versions can't be used anymore?

 

Upgrade.png

 

Many customers throughout the years have requested advance notice whenever older operating systems and SQL database versions would no longer be supported in future versions of Orion, allowing them sufficient time to properly plan for those upgrades. Deprecation does not mean that those versions can't be used, or that they are no longer supported at the time the deprecation notice is posted. Rather, those deprecated versions continue to remain fully supported, but that future Orion product releases will likely no longer support them. As such, all customers affected by these deprecation notices should take this opportunity to begin planning their migrations if they wish to stay current with the latest releases. So what exactly was deprecated with the Q1'17 Orion product releases?

 

Windows Server 2008 R2

 

Released on October 22, 2009, Microsoft ended mainstream support for Windows Server 2008 R2 SP1 six years later on January 13, 2015. For customers, this means that while new security updates continue to be made available for the aging operating system, bug fixes for critical issues will require a separate purchase of an Extended Hotfix Support contract agreement; in addition to paying for each fix requested. Since so few of our customers have such agreements with Microsoft, the only recourse, often times, is an unplanned, out-of-cycle, operating system upgrade.

 

Microsoft routinely launches new operating system versions, with major releases on average every four years, and minor version releases approximately every two. As new server operating system versions are released, customer adoption begins immediately thereafter; sometimes even earlier, during Community Technical Preview, where some organizations place production workloads on the pre-released operating system. Unfortunately, in order to leverage the technological advances these later versions of Windows provide, it occasionally requires losing backwards compatibility support for some older versions along the way. Similar challenges occur also during QA testing whenever a new operating system is released. At some point it's simply not practical to thoroughly and exhaustively test every possible permutation of OS version, language, hotfix rollup or service pack. Eventually the compatibility matrix becomes so unwieldy that a choice between quality or compatibility must be made; and really that's not a choice at all.

 

 

SQL Server 2008 / 2008 R2

 

SQL Server 2008 was released on August 6, 2008, with SQL 2008 R2 being released just four months shy of two years later, on April 21, 2010. Seven years later, there have been tremendous advances in Microsoft's SQL server; from the introduction of new redundancy options, to technologies like OLTP and columnstore indexes, which provide tremendous performance improvements. Maintaining compatibility with older versions of Microsoft SQL precludes Orion from being able to leverage these and other advances made in later releases of Microsoft SQL Server, many of which have potential to tremendously accelerate the overall performance and scalability of future releases of the Orion platform.

 

If you happen to be running SQL Server 2008 or SQL 2008 R2 on Windows Server 2008 or 2008 R2, not to worry. There's no need to forklift your existing SQL server prior to upgrading to the next Orion release. In fact, you don't even need to upgrade the operating system of your SQL server, either. Microsoft has made the in-place upgrade process from SQL 2008/R2 to SQL 2014 extremely simple and straightforward. If your SQL server is running on Windows Server 2012 or later, then we recommend upgrading directly to SQL 2016 SP1 or beyond so you can limit the potential for additional future upgrades when/if support SQL 2012 is eventually deprecated.

 

Older Orion Version Support for Windows & SQL

 

Once new Orion product module versions are eventually released which no longer support running on Windows Server 2008, 2008 R2, or SQL 2008/R2, SolarWinds will continue to provide official support for those previous supported Orion module versions running on these older operating systems and SQL server versions. These changes only affect Orion module releases running Orion Core versions later than 2017.1. If you are already running the latest version of an Orion product module on Windows Server 2008/R2 or SQL 2008/R2 and have no ability to upgrade either of those in the near future, not to worry. Those product module versions will continue to be supported on those operating system and SQL versions for quite some time to come.

 

Monitoring vs Running

 

While the next release of Orion will no longer support running on Windows or SQL 2008/R2, support for monitoring systems which are running on these older versions of Windows and SQL will absolutely remain supported. This also includes systems where the Orion Agent is deployed. What that means is if you're using the Orion agent to monitor systems running on Windows Server 2008 or Windows Server 2008 R2, rest assured that support for monitoring those older systems with the Orion Agent remains fully intact in the next Orion release. The same is also true if you're monitoring Windows or SQL 2008/R2 agentlessly via WMI, SNMP, etc. You're next upgrade will not impact your ability to monitor these older operating systems or SQL versions in any way.

 

 

32Bit vs 64Bit

 

Support for installing evaluations on 32bit operating systems will also be dropped from all future releases of Orion product modules, allowing us to begin the migration of Orion codebase to 64bit. In doing this, it should improve the stability, scalability, and performance for larger Orion deployments. Once new product versions begin to be released without support for 32bit operating systems, users wishing to evaluate Orion based products on a 32bit operating system are encouraged to contact Sales to obtain earlier product versions which support 32bit operating systems.

 

 

.NET 4.6.2

 

Current Orion product module releases, such as Network Performance Monitor 12.1 and Server & Application Monitor 6.4, require a minimum version of .NET 4.5.1. All future Orion product module releases built atop Core versions later than 2017.1 will require a minimum version of Microsoft's .NET 4.6.2, which was released on 7/20/2016. This version of .NET is also fully compatible with all current shipping and supported versions of Orion product module releases, so there's no need to wait until your next Orion module upgrade to update to this newer version of .NET. Subsequently, .NET 4.7 was released on 5/2/2017 and is equally compatible with all existing Orion product module versions in the event you would prefer to upgrade directly to .NET 4.7 and bypass .NET 4.6.2 entirely.

 

It's important to note that Microsoft's .NET 4.6.2 has a hard dependency on Windows Update KB2919355, which was released in May 2014 for Windows Server 2012 R2 and Windows 8.1. This Windows Update dependency is rather sizable, coming in between 319-690MB. It also requires a reboot before .NET 4.6.2 can be installed and function properly. As a result, if you don't already have .NET 4.6.2 installed, you may want to plan for this upgrade during your next scheduled maintenance window to ensure your next Orion upgrade goes smoothly and as quick as possible.

 

Minimum Memory Requirements

 

With many of the changes referenced above, minimum system requirements have also needed adjustment as well. Windows Server 2012 and later operating systems utilize more memory than previous versions. Similarly, .NET 4.6 can also utilizes slightly more memory than .NET 4.5.1. As we move forward however, 64bit processes inherently use more memory than the same process compiled for 32bit. To ensure users have a pleasurable experience running the next version of Orion products, we will be increasing the absolute minimum memory requirements from 4GB to 6GB of RAM for future versions of Orion product modules. The recommended minimum memory requirement however, will remain at 8GB.

 

While most readers themselves today would never consider running and using a Windows 10 laptop on a day-in-day-out basis with just 4GB of RAM, those same people also likely wouldn't imagine running an enterprise grade server based monitoring solution on a system with similar such specs either. If you do, however, find yourself in an environment running Orion on 4GB of RAM today, an 8GB memory upgrade can typically be had for less than $100.00. This can be done before the next release of Orion product modules and will even likely provide a significant and immediate improvement to the overall performance of your Orion server.

 

 

How to Prepare

 

All items listed above can be completed prior to the release of the next Orion product module versions and will ensure your next upgrade goes off without a hitch. This posting is intended to provide anyone impacted by these changes with sufficient notice to plan any of these upgrades during their regularly scheduled maintenance periods, rather than during the upgrade process itself. In-place upgrades of SQL, as stated above, are a fairly simple and effective process to get upgraded quickly with the least possible amount of effort. If you're running Orion on Windows Server 2008 or 2008 R2, in-place OS upgrades are also feasible. If either of these are not feasible or desirable for any reason, you can migrate your Orion installation to a new server or migrate your Orion database to a new SQL server by following the steps outlined in our migration guide.

 

Other Options

 

If for any reason you find yourself running Orion on Windows Server 2008, Server 2008 R2, or on SQL 2008/R2 and unable to upgrade, don't fret. The current releases of Orion product modules will continue to remain fully supported for quite some time to come. There is absolutely zero requirement to be on the latest releases to receive technical support. In almost all cases, you can also utilize newly published content from Thwack's Content Exchange with previous releases, such as Application Templates, Universal Device Pollers, Reports, and NCM Configuration Change Templates. When you're ready to upgrade, we'll be here with plenty of exciting new features, enhancements and improvements.

 

 

Planning Beyond The Next Release

 

At any given time, Orion supports typically a maximum of three major versions of the Windows Operating System and SQL database server. When a new server OS or SQL version is released by Microsoft, SolarWinds makes every effort possible to support up to four OS and SQL versions for a minimum of one Orion product module release. If at any time you find yourself four releases behind the most current OS or SQL server version, you may want to begin planning an in-place upgrade or migration to a new server during your next regularly scheduled maintenance window to ensure your next Orion product module upgrade goes flawlessly.

 

For your reference, below is a snapshot of Windows Operating Systems and SQL Server versions which will be supported for the next release of Orion product modules. This list is not finalized and is still subject to change before release. However, nothing additional will be removed from this list, though there could be additional version support added after this posting.

 

Supported Operating System VersionsSupported Microsoft SQL Server Versions
Server 2012SQL 2012
Server 2012 R2SQL 2014
Server 2016SQL 2016

We've all been there at some point or another. For some of us it's a daily ritual, for others, it's what haunts our dreams at night.

 

I'm speaking, of course, about troubleshooting complex multi-faceted IT issues which can (and often do) transcend functional silos within the overarching IT organization. Cloud, virtualization, hybrid IT, storage area networks, converged infrastructure etc., have all fundamentally transformed IT. Tasks which historically may have taken hours or even days, now take minutes, and some just seconds to complete. These historically, time consuming tasks have become so easy, in fact, that in some organizations they're fully or at least partially automated.

 

The story doesn't end at the infrastructure either. Instead of monolithic, single purpose, do everything, application servers; distributed application architectures, elasticity, and containerization have increasingly becoming the norm. While all these abstraction layers have helped address application scalability and availability, they have also made it significantly more difficult for those monitoring the health and performance of everything which contributes to the delivery of the services those applications provide.

 

The troubleshooting process itself is more entangled than ever before, often times requiring collaboration amongst many different functional silos within the organization. From the storage administrator, DBA, Virtualization admin, cloud architect, application designer, network engineer, DevOps, systems administrators, etc., the finger pointing begins right away. But where to begin? The Orion® Platform and its related product modules such as Network Performance Monitor, Server & Application Monitor, etc., can collect millions of different metrics from across the entirety of the IT environment. That's an overwhelming amount of data to parse through as the clock is ticking; the pressure mounts, and your SLA is hanging in the balance.

 

Many Orion administrators have created elaborate, purpose-built, custom summary dashboards, comprising many various chart resources to help consolidate relevant information related to specific business critical services and to aid in troubleshooting scenarios. The issues with this approach are varied. First, depending upon the complexity and elaborateness of the custom dashboard, the creation process can be both tedious and time consuming. Second, only those with Orion View Management rights have the necessary permissions required to build or modify these custom summary dashboards, placing a tremendous burden on the Orion administrator and making them the bottleneck for efficient troubleshooting. Third, there's the issue of maintaining these custom summary dashboards. Some larger organizations may have dozens or even hundreds of these for various business services, and if not properly maintained to reflect changes made throughout the organization, these dashboards become less and less useful for their intended purpose.

 

From the end-user's perspective, these dashboards help eliminate the need to navigate through a various multitude of views and dashboards in search of data needed to isolate the root cause. Provided, of course, the issue they're investigating occurred within the default time period shown within the chart resources. If it didn't, then the end-user must click on each chart resource individually to be taken to the Custom Chart View, where they can adjust the timeframe shown to the timeframe desired for that specific chart. This then defeats the entire purpose of the custom summary dashboard as a means to visually correlate data more easily for the specific time period when the issue occurred.

 

Enter PerfStack

 

With the release of Network Performance Monitor 12.1 RC1, and the impending release of Server & Application Monitor 6.4 RC1 comes a completely new method for visualizing and correlating data within the Orion web interface. We affectionately refer to this as 'PerfStack'. In part, the name represents the newfound performance analysis and correlation capabilities this feature brings to the Orion® Platform, enriched with relationship data which powers AppStack. The culmination of time series and relationship data is what sets PerfStack apart, allowing you to quickly sift through the massive amounts of data Orion products collect, eliminating noise, and allowing you to focus on what's truly relevant to the issue at hand.

 

Immediately upon upgrading to any of our latest release candidates you will notice a new option available under the 'Home' menu, entitled 'Performance Analysis', which will take you to the new PerfStack dashboard. By default, you will begin with a new analysis project, whereby you will need to start by adding at least one entity. In the throes of an active investigation into an ongoing issue,   the entity selected would typically be the one exhibiting the symptom. This could be the switch, router, virtual machine, host, (AKA: node), or something more specific like the application, LUN, array, or web transaction, to name only a few of the possibilities. Choose whatever the most logical starting point is in your investigation and note that you can add as many entities as you wish to your analysis project.

 

Performance Analysis Menu OptionAdd Entities
Performance Analysis.pngAdd Entities.png

 

Select Entities

 

 

Once you’ve added your entity/s to PerfStack, hovering your mouse over any of those entities in the list, you will notice two icons that appear to the right of the entity name. When clicked, the first icon brings in all other entities related to that object. This leverages existing AppStack relationship data, as well as additional relationship information not currently expressed within AppStack. This includes items such as Hardware Health sensors, network Interfaces, IIS™ Sites, application pools, etc. Relationship information within PerfStack allows you to dramatically accelerate the troubleshooting process and focus exclusively on what's likely related to the issue at hand. This prevents you from fumbling about, wasting time manually trying to figure out how things are related on your own.

 

Add Related EntitiesAvailable Metrics

 

Clicking on any entity name itself populates a list of all available metrics associated with that entity in the adjacent column. These metrics are categorized into collapsed groupings based on their type, any of which can be expanded to reveal individual metric tiles. These tiles can then be dragged onto the chart area on the right where the metric data is plotted.

 

 

 

Add as many metrics to the chart area as you desire. You can add multiple metrics to the same chart, as well as stack multiple charts on top of each other. PerfStack is also capable of combining data from disparate data sources into the same chart. For example, combine Storage Resource Monitor's LUN IOPS data with Network Performance Monitor's network latency and bandwidth data into the same chart to troubleshoot iSCSI performance issues. A feat never before possible within the Orion® Platform family of products.

 

Correlate Metrics Across Different Orion Product Modules
Multi-Product Chart.png

 

PerfStack also allows you to combine integer-based metrics with percentage-based metrics while maintaining the appropriate scale. This is accomplished by maintaining two separate x-axes when metrics of dissimilar types are combined within the same chart.

 

Combine Metrics of Dissimilar Units Within The Same Chart
Integer Pecent.png

 

Data for all metrics displayed within the chart area are automatically aligned across the same time period. Hovering your mouse over any chart area adds a vertical marker which tracks with your mouse movement to visually align all data points across the series. It also displays the date and time that datapoint was collected. As you move your mouse horizontally across the time period of the chart area, the values within the legend update to reflect the values aligned to the vertical marker.

 

 

The viewable time period can be adjusted globally, maintaining sync across all charts in PerfStack. Both relative and custom timeframes are available, allowing you to view things such as the last seven days of history, or focus on a particular event that occurred between 8am - 6pm last Tuesday, for example.

 

Adjust Time RangeSave your Masterpiece

 

Once you've completed your masterpiece, you can optionally save it for future reference. Charted metrics, the entities they're derived from, and the custom or relative time frame are all included as part of your saved project. Saved PerfStack projects can be loaded just as easily as they were saved with a top five most recently used PerfStack list making juggling between projects a snap. You can also save a copy of a project using Save As, or delete PerfStack projects you no longer need from within the More menu.

 

Load Saved PerfStack MRUDelete & Save As

 

Each individual Orion user can create, save, load, update, and delete their own works of art within PerfStack. Also, users aren't required to have Orion 'Admin' or 'View Management' rights to do so, either. Any Orion user can create as many PerfStack dashboards as they wish and manage them independently without assistance from the Orion Admin; something I'm sure is music to the ears of every Orion administrator.

 

Sharing is Caring

 

The most powerful PerfStack feature of all is the ability to collaborate with others within your IT organization; breaking down the silo walls and allowing teams to triage and troubleshoot problems across functional areas. Anything built in PerfStack is sharable. The only requirement is that the individual you're sharing with has the ability to login to the Orion web interface. Sharing is as simple as copying the URL in your browser and pasting it into email, IM, or even a helpdesk ticket.

 

 

When received, the URL provided allows others to instantly see exactly what you've found. They, in turn, can work from that URL, add their own metrics, and send it back without ever affecting your project. Similar behavior is also true if you wish to share a saved PerfStack. Sharing saved PerfStack projects with others allows the recipient access to view your saved PerfStack dashboard and any updates you may make to it in the future. Other users cannot modify your saved PerfStack project, but they can save their own copy, update it as needed, and share back their results.

 

Orion account limitations are fully respected by PerfStack, so there's no need to worry about users gaining access to information they shouldn't. If for any reason, a user should receive a link to a PerfStack project containing objects not permitted by their account restrictions, then any/all metrics related to those restricted objects would be automatically hidden from that user's perspective of the PerfStack project.

 

Coming Soon to a Theater (Monitor) Near You

 

PerfStack is a feature provided with all upcoming Orion product releases which are built atop Orion Platform v2017.1 or later. The list of supported modules include (but not limited to)...

 

  • Network Performance Monitor 12.1
  • Server & Application Monitor 6.4
  • NetFlow Traffic Analyzer 4.2.2
  • Virtualization Manager 7.x
  • Storage Resource Monitor 6.4
  • Web Performance Monitor 2.2.1

 

SolarWinds PerfStack Analysis Dashboard was engineered to allow Orion users to troubleshoot, isolate, and identify IT problems in ways never before possible. As our IT environments evolve, so too must the tools we use to monitor them. Cross silo collaboration is an essential ingredient to any successful IT organization, now and for the foreseeable future. PerfStack, like NetPath before it, are just tiny glimpses into what we have in store for the future of Orion, and we sincerely hope you like what you see.

Server & Application Monitor 6.2 included a boatload of great new features that are going to be difficult to top, but that isn't going to stop us from trying. Here is a sneak peek at just a few of the items the team is diligently plugging away on.

 

  • Cloud Infrastructure Monitoring
    • Amazon AWS
  • Optional Agent for Linux Applications and Servers
    • Allows for polling host and applications behind firewall NAT or proxies
    • Polling node and applications across multiple discrete networks that have overlapping IP address space
    • Allow for reliable and secure encrypted polling over a single port
    • Support low bandwidth, high latency connections
    • Full end to end encryption between the monitored host and the Orion poller
    • Store and forward capabilities allowing the agent to operate independently of the Polling engine when network connectivity is lost
  • Numerous AppStack Environment enhancements
  • Real-Time Performance Analysis
  • Native Log File Monitoring
  • Web Interface design improvements
  • Active Directory Discovery
  • Application Template Assignment to Groups (Static or Dynamic)
  • Automated Network Sonar Discovery Import
    • Automatic monitoring of newly found nodes, interfaces, volumes, and applications based on discovery profile criteria
  • Web Based SSH Client

Since the release of Server & Application Monitor (SAM) 6.2, the team has been busily plugging away on a long list of new features and general product enhancements.  Chief among them are improvements to the aesthetics and overall design of the Orion web interface. While not the primary focus of this blog post, it is near impossible to post screenshots for some of what we've been working on without divulging some sneak peeks into the very early stages of this interface design refresh. A follow-up blog post is currently in the works that will go into detail and explain our multi-phased approach for delivering a fresh, clean, and modernized interface for all products that run atop the Orion platform. Suffice it to say, it is our aim to accelerate overall Orion web interface performance, dramatically improve usability for many of the most common tasks, as well as refine and enhance the product's visual appearance as part of this endeavor. Continue watching the Product Blog for more specifics surrounding the Orion UI redesign, as well as opportunities to provide feedback to members of our user experience team regarding these improvements. Your feedback might just earn you some much deserved Thwack points that can be redeemed for some cool SolarWinds SWAG!

 

With that prologue out of the way, it's time to run through a few notable new features we've been working on that are sure to put a smile on your face. As always, your feedback on features such as these is essential; and the absolute best time to provide that feedback is during betas. So if you're anything like me and would rather try out the new features yourself rather than simply read about them, then short circuit this post entirely and click the big red button below. Otherwise strap in, adorn your reading glasses (if you need them) and soak in the geek goodness below as I walk through some of the new features planned for this release and expose a few glimpses of the web interface redesign.

 

SAM 6.3 Beta button.png

 

Active Directory Discovery

One of the many aspects we wanted to focus our attention on improving within this release is how servers are discovered in SAM. Network subnets, IP address ranges, and lists of individual IP addresses might seem like natural options for those of us who come from a network centric background. However, for those possibly unfamiliar with the networks design or IP addressing schema, Active Directory in many instances provides much or all of the information needed about the servers residing on the network.

 

Active Directory discovery can be added as an additional discovery method to any new or previously existing discovery profile and used in conjunction with the three previously available methods for complete coverage across the environment. 

 

Similar to the other three methods of discovery, multiple Active Directory domains may be used in the discovery profile. This is especially handy for large organizations that may have multiple domains running in their environment due to mergers and acquisitions, separation of internal business units, or even lab vs. production systems. Also, unlike Active Directory authentication to the Orion web console, there is no requirement for the Orion server to be in the same Active Directory domain as the domain controllers used for discovery.

Discovery 2 - Add Domain Controller.png

 

Active Directory has the distinct advantage of allowing for more precise and targeted discovery within the environment. Instead of using a very broad discovery technique such as subnets or IP address ranges, you can more surgically discover only those items you wish to monitor, such as servers and/or workstations. This is particularly useful for organizations using class B "/16" (65,534 IP address) or class A "/8" (16,277,214 ip addresses) subnets, where sequential network scanning techniques may take hours or even days to complete successfully. In environments such as these, much of that IP address space is unused, but it still must be swept to determine which IP addresses are in use and are not part of the discovery process. Active Directory however, has a complete database of all hosts on the network which are members of the domain. Leveraging that database allows for a much more rapid scan of servers and workstations running on the network that could be monitored by SAM.

 

Discovery 3 - Add Domain Controller.png

Discovery 4 - Select OUs.png

Once you've added the Active Directory domain you wish to discover and click "Next" you are shown a complete listing of all Containers and Organizational Units (OUs) in the domain hierarchy. By default all OUs and Containers are selected, including any future Organizational Units that may be created after the discovery profile creation process is complete. Selecting the root level domain object toggles between select/deselect all, and the individual checkboxes on the left allow you to select the specific OUs to include or exclude from this discovery profile. The checkbox to the right of each OU listed designates whether to include any sub-OUs that may be created under that Organizational Unit in the future. For example: you have a root level Organizational Unit named "California" because you have only one office in that region today, located in Los Angeles. Later a new office is brought online in San Francisco. As a result you may decide to create two sub-OUs under California named "LA" and "SF" to manage group policy separately for each of those offices. The "Include Future OUs" option allows for these types of changes to occur within an OU, sub-OU, or domain without the need to update SAM's discovery profiles that are used for recurring nightly scheduled rediscovery of new devices in the environment. If not applicable or desirable in your organization, this option can of course be disabled.

 

Automatic Monitoring

Another primary area we focused on for this release is reducing or outright eliminating the maintenance overhead required to keep SAM up to date as new systems are brought online. Too many of us have been in similar situations where a new critical business system is brought up in the environment, and the first time there's a reported problem or issue with the system there's immediately an exchange of finger pointing that occurs amongst the responsible parties attempting to assign blame for why the system wasn't being monitored. As a result many organizations have implemented rigid policies and processes surrounding the provisioning of new systems in an attempt to mitigate these blind spots on the network. Unfortunately even the best laid plans aren't immune from human fallacy, even those with the best of intentions.

 

With that in mind we aimed to provide a mechanism that would ensure that as new systems were brought up in the environment that they would be monitored without relying on someone in the organization to manually add them to SAM for monitoring; or dig through the nightly Network Sonar Discovery Results to select which new items should be monitored. If adding individual devices manually is more your speed, or thumbing through the Network Discovery Results is how you enjoy spending your morning "me" time, those options continue to remain intact and unchanged in this release.

Discovery 5 - Automatic Monitoring.png

 

When selecting "Automatically Monitor" from the "Monitoring Settings" step of the Network Sonar Discovery Wizard you may continue on by clicking "Next" and accept the recommended defaults (only "Up" interfaces, non-removable media volumes, etc.) or use your own preferences by clicking the "Define Monitoring Settings" button. Clicking this button takes you through a mini-wizard where you are given the ability to define what you'd like automatically monitored should they be found during the Sonar discovery process. These options include, but are not limited to, interface type (trunk, non-trunk) , state (up/down/shutdown/etc.) upon discovery, interface name (contains, does not contain), interface description (contains, does not contain), volume type (Fixed Disk, Mount Points, etc), and AppInsight Applications. Additional steps may appear within the mini-wizard depending upon which Orion modules are also installed alongside SAM.

 

The next time the Network Sonar Discovery runs, either at the completion of creating the new Discovery Profile or its next scheduled run, any items found meeting the criteria defined within the profile not already monitored in Orion, will be automatically monitored by SAM.

 

For nodes managed via the optional Agent that was included as part of the SAM 6.2 release, these automatically become managed nodes in Orion by default when they first register with the Orion server or additional polling engine using Agent Initiated mode. Monitoring of these hosts however is limited to status, response time, CPU, and memory, without taking some additional step to select the specific items you'd like monitored on those hosts. The new automatic monitoring option shown here allows you to predefine those items just for agent managed nodes, agentlessly managed nodes, or all nodes in the environment depending upon the settings defined within the discovery profile.

Discovery 6 - Automatic Monitoring - Select Volumes.png

 

There's still more in store for this release, but we are eager and anxious to get your feedback on some of the features already starting to near completion. Please note that the absolute best time to provide feedback is during the beta, as things are still very fluid and there's plenty of time to fix bugs, make adjustments, and alter the design before release. That's right, betas are intended not only as a mechanism for finding bugs, visual defects, or other things broken in the code, but also to address usability issues and design flaws as well. If you are interested in taking SAM 6.3 for a spin and kicking the tires on some of these (and other) features, simply sign-up here. The only requirement for participation in the beta is that you own an existing license of Server & Application Monitor which is currently under active maintenance.

If you frequent the various product and geek speak blogs here on Thwack, you've likely at one time or another stumbled upon some reference, and possibly sneak peek glimpses, into what has affectionately been referred to as the "AppStack". The Application Stack, or "AppStack" for short, is a term used to describe all the various moving parts that make up today's complex application delivery infrastructure. This begins at the bottom with the backend storage arrays where data is housed, through the various different virtualization layers, up to the server that hosts the application, until finally we reach the application itself. The AppStack Environment View shown below accompanies the SAM 6.2, VMAN 6.2, and SRM 6.0 beta releases.

 

SAM Button.pngVMAN Button.pngSRM Button.png

 

The image below isn't the latest incarnation of the Candy Crush sensation, but rather a visual representation of all the various infrastructure components that make up my lab environment. Historically, all of this status goodness was tucked away under each respective categories product tab. Correlation and association of these various objects was a mental exercise based on a working knowledge of the infrastructures initial deployment, or legacy information that has been passed down from systems administrator  to systems administrator before them. To make matters worse, todays infrastructure is dynamic and ever changing, so what you thought you knew about the organizational layout of your supporting infrastructure may have changed dozens, or even hundreds of times since it was initially deployed.

 

AppStack.png

 

The AppStack Environment provides a 10,000 foot overview of your entire environment. At first, this may seem a bit overwhelming as there's a lot of status information contained within a single view. To that end, our UX research team toiled tirelessly to ensure that the AppStack provides as much useful information possible, while reducing or completely eliminating any extraneous noise that could distract from identifying problems in the environment and their likely cause. Perhaps most unnerving to most when first presented with the AppStack Environment View is the lack of object names displayed. Well fret not my dear friend because our UX masterminds thought of everything!

 

In most cases, when trying to get a high level overview into the health status of the environment, you're trying to get as much information represented in as little real estate as possible. If the status is good (green) then likely it's not of any concern. For those objects that are in distress however, you may want to glean additional information into what they are before digging deeper. As with most things in Orion, mouse hovers are available extensively throughout the AppStack Environment view to expose information, such as the objects name and other important details. However, if you're trying to determine the object names for a multiple of objects in distress, a mouse hover is a fairly inefficient means for determining what those objects represent. To address this need you will find a "Show Names" link in the top left of the AppStack. Clicking on this link will expose the name of any object currently in distress. Object names for items that are up (green) remain hidden from view to reduce visual clutter, so it's easier to focus on the items currently in distress.

 

Show Names.png

 

 

The AppStack Environment functions as a status overview page that is valuable when visually attempting to identify issues occurring within the environment, such as in the case of a NOC view, or perhaps the view you keep on your monitor while you go about your usual daily routine.  Any changes in status are updated in real-time for all objects represented in the AppStack. No browser refresh necessary. What you see in the AppStack Environment view is a real-time representation of the status of your environment.

 

Leveraging application topology information gathered across various different products, from Server & Application Monitor (SAM), Virtualization Manager (VMAN), and the all new Storage Resource Monitor (SRM), Orion is now capable of automatically compiling relationships and displaying them in a meaningful fashion between all the various infrastructure components that make up the application stack. Object associations are updated and maintained in real-time, and automatically, as the environment changes. This is important in todays dynamic environments where VMs are vMotioned between hosts, and storage is so easily reprovisioned, reallocated, and presented to servers. If someone had to maintain these relationships manually, it would likely be a full time job that could drive a person insane!

 

Clicking on any object within the AppStack selects that item and displays all relevant relationships the object has to any other object represented within the AppStack Environment. In the case below, I've selected an Application that's currently in a "Critical" state. I can see in the selection bar that this is a Microsoft SQL Server; one I've been having a bit of trouble with lately, so I'm not at all surprised to see it in a critical state. From here I can see which server SQL is running on, the fact that it's obviously virtualized because I can also see the host, virtual custer, datacenter, and data store the VM resides upon as well. None of those appear to be my issue however, as their status is "green". Moving further down the AppStack I can see the volumes that the VM is using, the LUN where the Data Store this VM resides upon, and the Storage Pool itself. So far, so good. Wait a minute, what's that I see? The backend array this VM is running on appears to be having some trouble.

 

AppStack Selected.pngDouble clicking on the Array object, or selecting the array and clicking on the object name from within the selection bar (for those of you rocking a tablet or other touch enabled device) takes me to the Array Details view. There I can see the I/O on this array is exceptionally high. I should probably vMotion a few VMs off the hosts that are utilizing this array, or provision more storage to those hosts from different arrays and balance the VMs across them.

 

Selection Bar.png

 

In this example, the AppStack Environment view was able to cut through the all the various information Orion is capable of collecting across multiple products to expose a problem, provide context to that problem, and identify the root cause. This can be done across the entire environment, or custom AppStack Environment views can be created to focus on a specific areas of responsibility. Perhaps you're the Exchange Administrator, and all you care about is the Exchange environment. No problem! Creating a custom AppStack environment view is simple. You can filter the AppStack by virtually any property available in Orion, such as Application Name, or Custom Property by adding filter properties.

 

Narrow your Envionment.pngSave as New Layout.pngSave as new Layout Dialog.png

 

Once you've filtered the AppStack to your liking and saved it as new layout, you can reference it at any time from layout selector in the top right of the AppStack Environment view. These custom AppStacks can also be used in rotating NOC views for heads up displays, or added to any existing summary view.

 

In addition to this new AppStack Environment View, you will also find a contextual AppStack resource on the Details view of every object type that participates within the AppStack. This includes, but is not limited to...

 

  • Node Details (For Servers)
  • Application Details
  • Array Details
  • Group Details
  • Storage Pool Details
  • LUN Details
  • Storage Pool Details
  • Hyper-V Host Details
  • ESX Host Details
  • Cluster Details
  • Virtual Center Details
  • Datastore Details
  • Volume Details
  • vServer Details
New Layout - Microsoft Exchange.png

 

AppStack MiniStack.png

The AppStack Environment resource provides relevant contextual status information specific to the object details being viewed. The image on the right, taken from the Node Details view of the same SQL server shown in the example above, displays the relationships of all other monitored objects to this node. This context aware application mapping dramatically reduces time to resolution by consolidating all related status information to the object being viewed into a single, easily digestible resource.

 

Relationships aren't limited exclusively to the automatic physical associations understood by Orion however. These relationships can also be extended using manual dependencies to relate logical objects that are associated in other ways, such as SharePoint's dependency on the backend SQL server. This capability further extends the AppStack to represent all objects as they relate to the business service, and significantly aids in root-cause analysis of today's complex distributed application architectures.

 

Earn $100.00 & 2000 Thwack Points!

 

SAM 6.2, VMAN 6.2, and SRM 6.0 beta participants have been given a special opportunity to earn $100.00 and 2000 Thwack points simply for taking part in these betas and providing feedback. To participate you will need to sign-up to participate and install at least two beta products that integrate within the new AppStack Environment view.

 

If you already own Virtualization Manager, you can sign-up here to participate in the Virtualization Manager 6.2 beta, get it installed and integrated with SAM or SRM and you're well on your way to earning $100.00 and 2000 Thwack points. Please note though, that you MUST already own Virtualization Manager and be under active maintenance to participate in the Virtualization Manager 6.2 beta.

 

If you currently own Storage Manager, and are under active maintenance, you can sign-up here to participate in the SRM 6.0 beta. Install SRM alongside SAM or VMAN to earn yourself some quick holiday cash!

 

If you're not yet participating in the Server & Application Monitor 6.2 beta, then what are you waiting for? All SAM product owners under active maintenance are welcome and strongly encouraged to join. Simply sign-up here. If you also happen to own Virtualization Manager or Storage Manager, then now is a great time to try out these awesome combined beta releases, and earn a little cash in the process.

 

Space is limited, so please reply to this post letting us know that you're interested in participating. You'll not only fatten your wallet in the process, but you'll also be helping us to build better products! Here’s how it’s going down.

 

When:What you’ll do:What you receive:
When you receive the beta bits for 2 or more productsHave a 15 minute phone call with our UX team to review what to expect and tell us about your job and technical environmentMy eternal gratitude!
2 to 4 days after installing two or more participating beta productsSend us a 1 to 2 minute video telling us about your initial experiences with AppStack. You can make the video with whatever is easiest for you; most people use their phone.$50 Amazon gift card
7 to 10 days after installing two or more participating beta productsSend us another 1 to 2 minute video telling us about how you've used AppStack. What are your favorite things? What drives you crazy?$50 Amazon gift card
12- 14 days after installing 2 or more participating beta productsSpend one hour with us showing us how you use AppStack.  We’ll  meet using GoToMeeting so that you can share your screen and walk us through some typical use cases.2,000 thwack points

Up until this point, much of the noise surrounding the Server & Application Monitor 6.2 beta has been focused exclusively on a new optional agent that allows for (among many other things) polling servers that reside in the cloud or DMZ. More information regarding this new optional agent can be found in my three part series entitled "Because Sometimes You Feel Like A Nut" linked below.

 

 

If you can believe it, this release is positively dripping with other incredibly awesome new features and it's time now to turn the spotlight onto one that's sure to be a welcome addition to the product.

 

Since the advent of AppInsight for SQL in SAM 6.0, and AppInsight for Exchange in 6.1, you may have grown accustomed to the inclusion of a new AppInsight application with each new release. Well I'm happy to announce that this beta release of SAM 6.2 is no different, and includes the oft requested AppInsight for Microsoft's Internet Information Services (IIS).

 

 

HTML tutorial

 

DISCOVERY


As with all previous AppInsight applications, monitoring your IIS Servers with SAM is fairly straightforward. For existing nodes currently managed via WMI simply click List Resources from the Node Details view and select Microsoft IIS directly beneath AppInsight Applications. You will also see this option listed for any new IIS servers added individually to SAM and managed via WMI using the Add Node Wizard.

 

You can add AppInsight for IIS applications individually using the methods above, or en masse using the Network Sonar Discovery Wizard.  One-time Discovery and scheduled recurring discovery of IIS servers in the environment using Network Sonar are fully supported. Either method will allow you to begin monitoring all IIS servers running in the environment quickly and easily.

 

AppInsight for IIS has been designed for use with IIS v7.0 and greater running on Windows Server 2008 and later operating systems. To monitor earlier versions of IIS such as 6.0 and 6.5 running on Windows 2003 and 2003R2 respectively, you should use theInternet Information Service (IIS) 6 template available in the Content Exchange.

 

AppInsight for IIS discovery is currently limited to WMI managed nodes. For nodes managed via SNMP, ICMP, etc. you can manually assign AppInsight for IIS to the node no differently than any other application template in SAM.

List Resources.png

 

Network Sonar One Time Discovery.png

Network Sonar Discovery Results.png

 

CONFIGURATION

AppInsight for IIS Configure Server.png

AppInsight for IIS leverages PowerShell to collect much of its information about the IIS server. As such, PowerShell 2.0 must be installed on the local Orion server or Additional Poller to which the node is assigned. PowerShell 2.0 must also be installed on the IIS Server being monitored. Windows 2008 R2 and later operating systems include PowerShell 2.0 by default. Only if you are running Orion on Windows 2008 (non-R2) or are planning to monitor servers running IIS 7.0, will you need to worry about the PowerShell 2.0 requirement.

 

Beyond simply having PowerShell installed, Windows Remote Management (WinRM) must also be configured. This is true both locally on the Orion server, as well as on the remotely monitored IIS host. If you're not at all familiar with how to configure WinRM, don't worry. We've made this process as simple as clicking a button.

 

After discovering your IIS servers and choosing which of them you wish to monitor, either through the Add Node WizardList Resource, or Network Sonar Discovery, you will likely find them listed in the All Applications tree resource on the SAM Summary view in an "Unknown" state. This is because WinRM has not been configured on either the local Orion server or the remotely monitored IIS host. Clicking on any AppInsight for IIS application in an "Unknown" state from the All Applications resource launches the AppInsight for IIS configuration wizard.


When the AppInsight for IIS configuration wizard is launched you will be asked to enter credentials that will be used to configure WinRM. These credentials will also be used for the ongoing monitoring of the IIS application once configuration has successfully completed. By default the same credentials used to manage the node via WMI are selected. Under some circumstances however, the permissions associated with that account may not be sufficient for configuring WinRM. If that is the case, you can select from the list of existing credentials available from your Credential Library, or enter new credentials for use with AppInsight for IIS.

 

Once you've selected the appropriate existing, or newly defined credential for use with AppInsight for IIS, simply click "Configure Server". The configuration wizard will do the rest. It should only take a minute or two and you're up and monitoring your IIS server.

 

If configuring WinRM to remotely monitor your IIS server isn't your jam, or if perhaps you'd simply prefer not using any credentials at all to monitor your IIS servers, AppInsight for IIS can be used in conjunction with the new optional agent, also included as part of this SAM 6.2 beta. When AppInsight for IIS is used in conjunction with the agent you can monitor IIS servers running in your DMZ, remote sites, or even in the cloud, over a single encrypted port that's NAT friendly and resilient enough to monitor across high latency low bandwidth links.

 

MONITORING

 

Sites and Pools.pngAs with any AppInsight application, AppInsight for IIS is designed to provide a near complete hands off monitoring experience. All Sites and Application Pools configured on the IIS server each appear in their respective resources. As Sites or Application Pools are added or removed through the Windows IIS Manager, those Sites and Application Pools are automatically added or removed respectively from monitoring by AppInsight for IIS. This low touch approach allows you to spend more time designing and building your IT infrastructure, rather than managing and maintaining the monitoring of it.

 

Each website listed in the Sites resource displays the current status of the site, it's state (started/stopped/etc.), the current number of connections of that size, the average response time, and whether the side is configured to automatically start when the server is booted.

 

It is all too common for people to simply stop or disable the Default Web Site or other unused sites in IIS rather than delete them entirely. To reduce or eliminate false positive "Down" alert notifications in these scenarios, any sites that are in a Stopped state when AppInsight for IIS is first assgined to a node are placed into an unmanaged state automatically. These sites can of course be easily re-managed from the Site Details view at anytime should you wish to monitor them.

 

The Application Pools resource also displays a variety of useful information, such as the overall status of the Application Pool, it's current state (stopped/started/etc.), the current number of worker processes associated with the pool, as well as the total CPU, Memory and Virtual Memory consumed by those worker processes. It's the perfect at-a-glance view for helping identify runaway worker processes, or noisy neighbor conditions that can occur as a result of resource contention when multiple Application Pools are competing for the same limited share of resources.

 

As one might expect, clicking on a Site or Application Pool listed in either of these resources will direct you to the respective Site or Application Pool details view where you will find a treasure trove of valuable performance, health, and availability information.

 

SERVER EXECUTION TIME

Response Time.png

 

The release of Network Performance Monitor v11 included an entirely new method of monitoring end user application performance in relationship to network latency with the advent of Deep Packet Inspection, from which the Quality of Experience (QoE) dashboard was born. The TopXX Page Requests by Average Server Execution Time resource is powered by the very same agent as the Server Packet Analysis Sensor that was included in NPM v11. AppInsight for IIS complements the network and application response time information provided by QoE by showing you exactly what pages are taking the longest to be served up by the IIS server.

 

This resource associates user requested URLs with their respective IIS "site", and its average execution time. Expanding any object in the list displays the HTTP verb associated with that request. Also shown is the date and time of the associated web request, the total elapsed time, IP address of the client who made the request, and any URL query parameters passed as part of the request.

 

New linear gauges found in this resource now make it possible to easily understand how the value relates to the warning and critical thresholds defined. Did I just barely cross over into the "warning" threshold? Am I teetering on the brink of crossing into the "critical threshold? These are important factors that weigh heavily into the decision making process of what to do next.

 

Perhaps you've just barely crossed over into the "warning" threshold and really no corrective action is required. Or maybe you've blown so far past the "critical" threshold that you can barely even see the "good" or "critical" thresholds anymore and a full scale investigation into what's going on is in order. In these cases, understanding where you are in relation to the thresholds defined is critical to determining both the severity of the incident, as well as measuring a sufficiently adequate response.

 

Server execution time is the time spent by the server processing the users request. This includes the web server's CPU processing time, as well as backend database query time, and everything in between. The values shown in this resource are irrespective of network latency; meaning, page load times will never be better than what's shown here in this resource without backend server improvements, regardless of what network performance looks like. Those improvements could be as simple as rebuilding database indexes, defragmenting the hard drive, or adding additional RAM to the server. Either way, high server execution time means users are waiting on the web server or backend database queries to complete before the page can be fully rendered.

 

AppInsight for IIS - Management.png

REMEDIATION

 

What good is the entire wealth of information that AppInsight for IIS provides if there is no way to remediate issues when they occur?

In addition to a powerful assortment of key performance indicators, you will notice new remediation options available within the Management resource of the AppInsight for IIS "Site Details" and "Application Pool Details" views. Within each respective resource is the ability to stop, start, and even restart the selected site or application pool, as well as unmanage. Remediation actions executed through the web interface are fully audited, no differently than terminating processes through the Real-Time Process Explorer, or stopping/starting/restarting services via the Windows Service Control Manager.

IIS Alert Trigger Action.png
In conjunction with one of the many other improvements also included in the SAM 6.2 beta, it is now possible to automate these IIS remediation actions from within the all new web based Alert Manager. Not only can you say, restart a site that has failed, or stop an Application Pool that's running amuck, but you can perform those remediation actions against any IIS site or Application Pool in your environment regardless if it's the site or application pool in distress. This is important for complex distributed applications where issues with backend application servers or database servers may require a restart of the frontend IIS site or application to resolve. Now this can be completely automated through the Advanced Alert Manager, and you can get some much need shuteye.


These are just a few of the capabilities of AppInsight for IIS. If you'd like to see more, you can try it out for yourself by participating in the SAM 6.2 beta. To do so, simply sign-up here. We thrive on feedback, both positive and negative. So kick the tires on the new SAM 6.2 beta and let us know what you think in the SAM Beta Forum.

 

Please note that you must currently own Server & Application Monitor and be under active maintenance to participate in this beta. Betas must be installed on a machine separate from your production installation and used solely for testing purposes only. Also, if you're already participating in the NPM v12 beta, the SAM 6.2 beta can be run on the same server, alongside the NPM v12 beta.

As promised, the long awaited and highly anticipated Server & Application Monitor (SAM) 6.2 Beta is now available for download. The premiere feature of this SAM beta is the new optional agent, which is intended to address key environmental scenarios where conventional agentless monitoring techniques are either impractical or impossible to leverage. Some of these scenarios include, but are not limited to, monitoring Windows hosts within the DMZ over a single fixed port; monitoring servers in remote branch offices over high latency, low bandwidth connections; or monitor the servers you have hosted in cloud based services, such as Amazon EC2, Azure, or Rackspace. For even more examples you can check out Part 1 and 2 of this blog series at the links below.

 

 

If you can believe it, I still have plenty more examples of where this agent might prove beneficial in your environment. I'll be covering more of those in another follow-up later on. For this post though, I want to cover a few of the different agent deployment methods available in the beta.

 

As discussed earlier, most agent based solutions rightfully deserve the negative reputations they have received over the years. Many of the negative connotations associated with those solutions surround abysmal management of the agent software on which they are dependant. With SolarWinds heritage of simplicity and strong emphasis on ease of use in all things we do, we firmly believe we are uniquely qualified to address many of the problems that have long plagued agent based solutions of the past. The first way in which we address this is by making the agent optional.  Striving to be the absolute best agentless management and monitoring solution is in our DNA and will remain so for the foreseeable future.

 

Everyone knows that the biggest headaches suffered at the hands of typical agent-based solutions has been the initial deployment and continual upkeep of the agents themselves. Agentless solutions allow you to install software on a centralized server and you're up and monitoring in no time. As new versions are released, you simply upgrade the server where the monitoring solution is installed and you're back up and running. The only thing left to do at this point is hit the big red button you got from your local office supply chain and call it a day.

 

With this in mind, as we set out to build this agent we were determined to ensure that it was not only incredibly powerful and flexible, but that is was also simple to deploy and easy to maintain. Not just easy in comparison to previous generations of agent based solutions, but "easy" by even agentless standards. If you would like to try out this new agent included in the SAM 6.2 beta and follow along, click the button below to sign-up.

thwack-blue.png

Agent Deployment - Add Node Wizard

 

For servers within your environment, Agent deployment is as simple as adding a new node to Orion. From within the Add Node Wizard you will notice a new "Agent" option listed alongside the familiar ICMP, SNMP, WMI, and External polling methods. After entering the IP address, hostname or fully qualified domain name of the server you wish to monitor, choose Agent as the method for polling the node. Selecting this new Agent option then prompts you to provide administrative credentials. These credentials are used solely for the purpose of installing the agent on the remote host. Once the agent is fully deployed to the remote host, the Local System account will be used for all node polling functions. After the credentials have been entered click "Next". Orion will then validate the credentials entered and check to see if the Agent software is already installed on the host. If it is not, you will be prompted to install the Agent software. Clicking "Start Install" will then begin the process of remotely deploying the Agent to the host, and a progress indicator will appear denoting the progress of the installation. Remote agent deployment typically takes a minute or two to complete, but across WAN links installation may take longer. If you don't feel like waiting around for the installation to complete you can click on the "Go to Manage Agents while install continues" link in the progress window. Deployment and installation will continue in the background allowing you to work on other things while you wait. If you choose to leave the Add Node Wizard during agent deployment you will be notified via the Notification Banner at the top of the screen once the agent is installed. Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor on the node.


If you opt to continue through the Add Node Wizard process throughout the installation of the agent, you will be walked through the rest of the existing Add Node Wizard process flow that you are likely already familiar with. You will be prompted to select which resources on the host you wish to monitor (Volumes, Interfaces, Hardware Health, Asset Inventory, AppInsight applications, etc.) as well as select which application templates you'd like to assign to the node. The final step of the Add Node Wizard allows you to review the node properties, update any Custom Properties, or revise any node thresholds and polling intervals. When you're done reviewing the node properties, simply click the "Ok, Add Node" button to complete the process of adding the agent managed node to Orion.

Agent Deployment Wizard

 

If deploying agents individually isn't your speed, you can opt instead to deploy agents to multiple endpoints simultaneously from within the Orion web interface using the Agent Deployment Wizard. Located under [Settings -> Manage Agents] appears the "Add Agent" option. Clicking this button will walk you through the process of deploying the agent to any existing managed Windows node within Orion. You can also specify the IP addresses of Windows hosts within your environment that are not yet Orion managed nodes. To deploy an agent to an existing managed node in Orion, select it from the grid displaying the full list of WIndows nodes managed in your Orion environment. To deploy the agent to Windows hosts not yet managed by Orion, simply enter the IP address or hostname and click "Add to list". Once you've compiled the full list of hosts you wish to deploy the agent to, click "Next" to proceed on to the next step within the Wizard.

 

The next step is to provide credentials for deploying the agent to the selected hosts. You can select each host individually or multiple hosts in bulk and assign credentials to use for agent deployment. Credentials are validated as they are assigned to hosts, which helps eliminate potential agent deployment failures. When all hosts have valid credentials assgined you can click the "Deploy Agent" button to begin the agent deployment process.


While agents are being deployed you can continue working within the Orion web interface and will be notified via the Notification Banner at the top of the screen once the agents have been deployed. Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor for each node. At any time you can check the progress of the Agent deployment process by going to "Manage Agents" under "Settings". This is also where you will find any potential errors related to agent deployment processes or edit agent settings.


Regardless of which push deployment method used, be it the Add Node Wizard or the Agent Deployment Wizard, you will need to ensure that TCP Port 445 is open from the Orion server to the hosts you wish to deploy the agent. The agent must also be able to communicate back to the Orion server over TCP Port 17778. For more information on agent deployment requirements you can reference the NPM v11.0 QoE Agent Deployment Guide.

Mass Agent Deployment Option

Mass Agent Deployment Option.png

Agent deployment from within the Orion server itself may be the easiest way to manage one, or even dozens of hosts within your environment, but what if you need to manage hundreds or even thousands of hosts using the agent? What if the hosts you're trying to manage are outside your environment and aren't directly accessible from the Orion server via RPC, such as host in the cloud or at a branch office behind NAT?


In cases such as these, it may be beneficial to utilize a software distribution solution to deploy the agent to the hosts you wish to manage. These can be software distribution tools built natively into Windows such as Group Policy, or commercial products like System Center Configuration Manager or SolarWinds Patch Manager to name a few. If you have servers running in the cloud, such as Amazon EC2 you may want to bundle the Agent as part of the server so that any dynamic elastic instances created are also managed in Orion. If you happen to be hosting servers on Azure, you can leverage Web Deploy to distribute the Agent to those servers as well. Really any solution that allows you to distribute MSI packages can be utilized to deploy the agent software.


You will find everything you need for mass agent deployment within the Orion web interface under [Settings ->  Agent Settings -> Download Agent Software] as pictured on the left. All agent settings that will be used during deployment can be preconfigured here, such as agent communication method ("Agent Initiated" or "Server Initiated"), as well as which polling engine the agents should communicate with. In the case of Agent Initiated Communication, you can specify an alternate IP address, hostname, or Fully Qualified Domain Name the agent should communicate with in the event the Orion server itself is hidden behind a firewall using address translation.


All preferences selected within this web interface are contained inside the Microsoft Transform (MST) file, which serves as the configuration setting for the Windows Installer (MSI) Package. Both the MST and MSI files are used together in conjunction with your software distribution mechanism of choice to deploy the agent software with the preferences selected here.


As agents are deployed within the environment or new cloud instances pre-packaged with the agent software installed come online, these hosts will begin registering with the Orion server and become managed nodes within Orion automatically. Thus dramatically reducing management overhead. As agents automatically register with the Orion server and become managed nodes within Orion, admins will be apprised through the Notification Banner at the top of the Orion web interface. Automatic registration and node management can, of course, be optionally disabled under [Settings -> Agent Settings -> Define Global Agent Settings] for environments where this behavior may not be desirable. When these options are disabled, agents must be individually allowed to register using the [Add Agent -> Connect to a previously installed agent] option located under Manage Agents section of the Settings view.

Manual Agent Deployment Option

 

 

If deploying the Agent software from within the Orion web interface isn't possible, due to NAT, firewall policies, or access control lists, and group policy or other software deployment mechanisms aren't really your thing, the agent can of course be installed manually on the host you wish to monitor. The agent software can be downloaded from the Orion web interface under [Settings ->  Agent Settings -> Download Agent Software] from the host where you plan to install the Agent software. Alternatively the agent installer is a mere 16MB in size, which is small enough for most environments that it can be emailed to engineers in the field as they bring new services online.

 

During the manual installation of the the Agent you are prompted to provide information, such as the IP address of the Polling Engine the agent will communicate with and your Orion credentials so that the agent can connect and register with the Orion server. Once the installation is complete the host where the agent was installed will automatically register with the Orion server and become a managed node. You will also be notified via the Orion web interface in the Notification Banner that a new agent has registered with the Orion server and become a managed node.Clicking on the notification within the banner takes you to the Manage Agents view where you are given the opportunity to choose the resources you wish to monitor on the node. If you would rather be notified via email, syslog, SNMP Trap, etc. you can optionally configure an alert to notify you of any new agents registered with the system.


Agent Management

Global Agent Settings.png

 

One of the biggest headaches associated with traditional agents has been maintaining them as new versions are released. Commonly, once the management server itself is upgraded you are blind to what's going on within the environment until all agents are also updated to the same version as the server. This means that a coordinated effort is required to properly upgrade the management server and all associated agents simultaneously to limit the amount of time you're without visibility into the environment. The additional overhead and orchestration required to successfully accomplish such an endeavor is commonly deemed not worth it, and upgrades are avoided unless deemed absolutely essential. Even then, the process is nightmarish at best.

 

While developing the Agent it was our intent to make it as much of a hands off experience as agentless monitoring is today. This means building an agent that is completely self maintaining. As new versions of SAM, NPM, or other products that utilize the Agent are released, the agent automatically updates itself once the Orion server is upgraded. Agents update themselves over the same communication channel the agent uses for polling, allowing agents that were deployed to hosts behind firewalls, proxies, or in the cloud to be updated simply and transparently.

 

For instances where automatic agent updates may not be desired, this feature can be disabled both globally or on an individual agent by agent basis from within the Orion web interface. In the event automatic agent updates are disabled, you still have the ability to approve agent updates manually through the Orion web interface. This affords you the ability to control exactly when agent updates occur on an individual agent by agent basis without the need to manage agent updates separately through other software distribution methods.

Delete Agent Node.png

Another common point of contention associated with agents is cleaning up after them. Accidentally deployed an agent to a server you didn't mean to monitor, but don't want to deal with the hassle of uninstalling the agent? No problem. Whenever you attempt to delete an Agent managed node in Orion you are given the option to uninstall the agent software from that host. This works for individual nodes deleted from Orion or multiple nodes selected at the same time. Unlike agent deployment however, uninstalling the Agent from the Orion web interface does not require connectivity to the agent managed host via RPC. Instead, the uninstall command occurs over the same communication channel the agent uses for polling. This means you can remotely uninstall agents that were deployed to hosts behind firewalls, proxies, or in the cloud from the comfort of the Orion web interface.


These are just a few of the ways this new agent is designed to make management and monitoring simpler than other agent based products you may have used in the past. All these great new capabilities are available now in the latest Server & Application Monitor 6.2 beta. If you currently own Server & Application Monitor and are under active maintenance we would love you to try out the new agent and give us your feedback. Simply sign-up here to download the SAM 6.2 beta and participate.

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.