Orion Platform 2019.2 - Additional Improvements

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 Prompt	Error 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.4	Orion 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.

PerfStack Links

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.

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.

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.