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.
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/Transfer||Top 25 Avg. Disk sec/Transfer||Top XX Avg. Disk sec/Transfer|
|Top 10 Nodes by Average Response Time||Top 25 Nodes by Average Response Time||Top XX Nodes by Average Response Time|
|Top 10 Nodes by Average CPU Load||Top 25 Nodes by Average CPU Load||Top XX Nodes by Average CPU Load|
|Top 10 Disk Queue Length||Top 25 Disk Queue Length||Top XX Disk Queue Length|
|Top 10 Volumes by Disk Space Used||Top 25 Volumes by Disk Space Used||Top XX Volumes by Disk Space Used|
|Top 10 Nodes by Percent Memory Used||Top 25 Nodes by Percent Memory Used||Top XX Nodes by Percent Memory Used|
Top 10 Nodes by Percent Packet Loss
|Top 25 Nodes by Percent Packet Loss||Top XX Nodes by Percent Packet Loss|
|Top 10 Nodes by Current Response Time||Top 25 Nodes by Current Response Time||Top XX Nodes by Current Response Time|
|Top 10 Total IOPS||Top 25 Total IOPS||Top XX Total IOPS|
|Nodes with High Average CPU Load||Volumes with High Percent Usage||Nodes 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.
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/22.214.171.124.126.96.36.199.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 Router||Cisco C1111-8PLTELAWH Router|
|DELL S5000||Cisco C1111-8PLTELAWF Router|
|DELL S4810-ON||Cisco C1111-8PWE Router with WLAN E domain|
|DELL S6000-ON||Cisco Aironet 1815|
|DELL S4048-ON||Cisco Aironet 1540|
|DELL S3048-ON||Cisco Catalyst 2960L-24TQ-LL Switch|
|DELL S3148P||Cisco Catalyst 2960L-48TQ-LL Switch|
|DELL S3124P||Cisco Catalyst 2960L-24PQ-LL Switch|
|DELL S3124F||Cisco Catalyst 2960L-48PQ-LL Switch|
|DELL S3124||Cisco Catalyst 9407R Switch|
|DELL S6100||Cisco Catalyst 94010R Switch|
|DELL S6010||Cisco C1111-4P Router|
|DELL S4048T||Cisco C1111-4PLTEEA Router with Multimode Europe and North America Advanced LTE|
|DELL S3148||Cisco C1111-4PLTELA Router with Latin America Multimode and Asia Pacific Advanced LTE|
|DELL Z9500||Cisco C1111-4PWE Router with WLAN E domain|
|DELL Z9100||Cisco C1111-4PWB Router with WLAN B domain|
|DELL S4148F||Cisco C1111-4PWA Router with WLAN A domain|
|DELL S4148T||Cisco 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 Applience||Cisco C1111-4PWH Router with WLAN C domain|
|Corvil CNE Appliance||Cisco C1111-4PWR Router with WLAN R domain|
|Corvil CNE Appliance||Cisco C1111-4PWF Router with WLAN K domain|
|FortiWeb 1000D||Cisco C1111-4PWD Router with WLAN D domain|
|Fortinet Fortigate 280D-POE||Cisco C1116-4P Router with VDSL/ADSL|
|FortiGate 500D||Cisco C1116-4PLTEEA Router with Multimode Europe and North America Advanced LTE|
|FortiGate 600D||Cisco C1117-4P Router with VDSL/ADSL|
|FortiWeb 4000D||Cisco C1116-4PWE Router with WLAN E domain|
|Pulse Secure IC4000||Cisco C1117-4PLTEEA Router|
|Pulse Secure MAG-2600||Cisco C1117-4PLTELA Router|
|Pulse Secure PSA-3000||Cisco C1117-4PWE Router with WLAN E domain|
|Pulse Secure PSA-5000||Cisco C1117-4PWA Router with WLAN A domain|
|Pulse Secure PSA-7000c||Cisco C1117-4PWZ Router with WLAN Z domain|
|Pulse Secure PSA-7000f||Cisco C1117-4PM Router with VDSL/ADSL|
|9982P2ET||Cisco C1117-4PMLTEEA Router|
|IAP-325||Cisco C1117-4PMWE Router with WLAN E domain|
|IAP-315||Cisco C1112-8P Router|
|ClearPass Policy Manager CP-HW-5K||Cisco C1112-8PLTEEA Router with Multimode Europe and North America|
|6548 Switch||Cisco C1113-8P Router|
|Internal Management Module Switch||Cisco C1113-8PM Router with VDSL/ADSL|
|Annuncicom||Cisco C1113-8PLTEEA Router|
|Instreamer||Cisco C1113-8PLTELA Router|
|DataDomain 9300||Cisco C1113-8PMLTEEA Router|
|S6720-54C-EI-48S-AC||Cisco C1113-8PWE Router with WLAN E domain|
|Lantronix EDS4100||Cisco C1113-8PWA Router with WLAN A domain|
|Xerox DocuColor 242||Cisco C1113-8PWZ Router with WLAN Z domain|
|ColorQube 9301||Cisco C1113-8PMWE Router with WLAN E domain|
|D110||Cisco C1113-8PLTEEAWE Router|
|Palo Alto PA-5200||Cisco C1113-8PLTELAWE Router|
|Palo Alto PA-5200||Cisco C1113-8PLTELAWZ Router|
|Palo Alto PA-220||Cisco C1114-8P Router|
|H3C S5560-54C-EI||Cisco C1114-8PLTEEA Router with Multimode Europe and North America|
|H3C S12504X-AF||Cisco C1115-8P Router|
|H3C S6520-48S-EI||Cisco C1115-8PLTEEA Router with Multimode Europe and North America Advanced LTE|
|LP-1030||Cisco C1115-8PM Router with VDSL/ADSL|
|TSM-24-DPS||Cisco C1115-8PMLTEEA Router|
|VMR-HD4D30||Cisco C1118-8P Router(ciscoC11188P)|
|NPS-8-ATS||Cisco C1116-4PLTEEAWE Router|
|vMX||Cisco C1117-4PLTEEAWE Router|
|Juniper Virtual Route Reflector (vRR)||Cisco C1117-4PLTEEAWA Router|
|Juniper ACX2200||Cisco C1117-4PLTELAWZ Router|
|Juniper ACX5048||Cisco C1117-4PMLTEEAWE Router|
|Juniper ACX5096||Cisco 807 Industrial Integrated Services Routers|
|Juniper vSRX||Cisco 807 4G LTE Industrial Integrated Service Router|
|Juniper SRX345||Cisco 807 4G LTE Industrial Integrated Service Routers with multi-mode Global (Europe & Australia) LTE/HSPA+|
|Juniper ACX2100||Cisco 807 4G LTE Industrial Integrated Service Router|
|Juniper ACX1100||Cisco 807 4G LTE Industrial Integrated Service Routers with multi-mode AT&T and Canada LTE/HSPA+|
|Juniper EX3400-24T||Cisco Catalyst 9500 series with 32 Ports of 100G/32 Ports of 40G|
|Juniper QFX10002-72Q||Cisco Catalyst 9500 series with 32 Ports of 40G/16 Ports of 100G|
|Juniper QFX10008||Cisco Catalyst 9500 series with 48 Ports of 1G/10G/25G + 4 Ports of 40G/100G|
|WIB 8000||Cisco Catalyst 9500 Router with 24 Ports of 1G/10G/25G + 4 Ports of 40G/100G|
|Meraki Dashboard||Cisco Catalyst 9500 Series Switch|
|Xerox ApeosPort-IV C3375||C9500-16X|
|Xerox ApeosPort-V C6675 T2||IR829M-LTE-LA-ZK9|
|DCS-7060CX2-32S||Cisco C1109-2PLTEGB 2 ports GE LAN M2M Router with Multimode LTE WWAN Global|
|SX6036||Cisco C1109-2PLTEUS 2 ports GE LAN M2M Router with Multimode LTE WWAN US|
|SX6036||Cisco C1109-2PLTEVZ 2 ports GE LAN M2M Router with Multimode LTE WWAN Verizon|
|MSB7800-ES2F||Cisco C1109-2PLTEAU 2 ports GE LAN M2M Router with Multimode LTE WWAN Australia and New Zealand|
|F5 BIG-IP 10350v||Cisco C1109-2PLTEIN 2 ports GE LAN M2M Router with Multimode LTE WWAN India|
|BIG-IP i2800||Cisco C1101-4P 4 Ports GE LAN Router|
|F5 Networks BIG-IP i4600||Cisco C1101-4PLTEP 4 Ports GE LAN Router|
|Delphix DB Engine||Cisco C1101-4PLTEPWE 4 Ports GE LAN Router|
|TSC ME240||Cisco C1101-4PLTEPWB 4 Ports GE LAN Router|
|Dell S4048-ON||Cisco C1101-4PLTEPWD 4 Ports GE LAN Router|
|Dell S6000-ON||Cisco C1101-4PLTEPWZ 4 Ports GE LAN Router|
|CX923de||Cisco C1101-4PLTEPWA 4 Ports GE LAN Router|
|OmniSwitch 6450-48L||Cisco C1101-4PLTEPWH 4 Ports GE LAN Router|
|OmniSwitch 6450-P10||Cisco C1101-4PLTEPWQ 4 Ports GE LAN Router|
|Alcatel OmniSwitch 6450-C48X||Cisco C1101-4PLTEPWR 4 Ports GE LAN Router|
|Alcatel OmniSwitch 6450-P48X||Cisco C1101-4PLTEPWN 4 Ports GE LAN Router|
|Alcatel OmniSwitch 6450-U24||Cisco C1101-4PLTEPWF 4 Ports GE LAN Router|
|Alcatel OmniSwitch 6350-P48||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2P)|
|OmniSwitch 6860E-U28||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWB)|
|InfoBlox ND-1400||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWE )|
|TelePresence MCU 5320||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWD)|
|Cisco IE 2000-16PTC-G-NX Industrial Ethernet Switch||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWZ)|
|Cisco IE 2000-4S-TS-G-L Industrial Ethernet Switch||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWA)|
|Cisco IE-2000U-4S-G Industrial Ethernet Switch||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWH)|
|Cisco C887VAM Integrated Series Routers||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWQ)|
|Cisco 897 Multi-Mode VDSL2/ADSL2+ POTS Annex M with Multi-Mode 4G LTE Router||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(iscoC11094PLte2PWN)|
|Cisco C899 Secure Gigabit Ethernet with Multi-mode 4G LTE Router||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWR)|
|Aironet 1572EC Outdoor Access Point||Cisco C1109-4PLTE2P 4 Ports GE LAN M2M Router(ciscoC11094PLte2PWF)|
|Cisco Catalyst 6824-X-LE-40G||Cisco C9407R|
|Cisco Firepower NGFW 4140||Cisco 1000V|
|Cisco NCS 5001||Cisco Nexus 3132Q Switch|
|Cisco NCS 5002||Cisco UCS 6332 32-Port Fabric Interconnect|
|Cisco 897 Multi-mode VDSL2/ADSL2+ POTS with Multi-Mode 4G LTE Router||Cisco Nexus 5672UP Switch|
|Cisco NCS 1002||UCS 6332-16UP Fabric Interconnect|
|Cisco NCS 5508||Cisco Nexus 31128PQ Switch|
|Cisco NCS 5502-SE||Cisco Nexus 3132|
|Cisco 897VAGLTELAK9-4G LTE Latin America router with 1 Giga Ethernet WAN||Cisco Nexus 3172|
|Cisco 819 Non-Hardened 4G LTE M2M with Dual Radio 802.11n WiFi Router||Cisco Nexus 3172|
|Cisco 819 Non-Hardened 4G LTE M2M with Dual Radio 802.11n WiFi Router||Cisco Nexus Nexus 9236C|
|Cisco Aironet 1560||Cisco Nexus 31108PC-V|
|C899G-LTE-LA-K9 4G router with 1 Giga Ethernet WAN, 1 SFP (Small Form-factor Pluggable) Giga Ethernet WAN||Cisco 3172|
|C819G-LTE-LA-K9 Router with 1 Gigabit Ethernet WAN, 4 Fast Ethernet LAN||Cisco 9232C|
|Cisco 4221 ISR||Nexus 93180YC-FX|
|Cisco 4221 Integrated Services Router||Nexus 9348GC-FXP|
|Cisco Catalyst CDB-8U Switch||Cisco Nexus 9K C9364C|
|Cisco Catalyst CDB-8P Switch||Cisco 7600 Series Route Switch Processor 720 with 10 Gigabit Ethernet Uplinks|
|Cisco NCS 5501||WS-X45-SUP9-E (Cisco Catalyst 4503-E Switch Module )|
|Cisco NCS 5502||Cisco 3172|
|Cisco 829 4G LTE Industrial Integrated Service Router||Cisco SGE2000 10/100/1000 Ethernet Switch|
|Cisco 829 4G LTE Industrial Integrated Service Routers with multi-mode LTE/HSPA+ with 802.11n||SF550X-24|
|Cisco 829 4G LTE Dual-modem Industrial Integrated Service Router||SF550X-24P|
|Cisco 829 4G LTE Dual-modem Industrial Integrated Service Routers with multi-mode LTE/HSPA+ with 802.11n||SF550X-24MP|
|Cisco 809 4G LTE Industrial Integrated Service Router||SF550X-48|
|Cisco 809 4G LTE Industrial Integrated Service Routers with multi-mode LTE/HSPA+||SF550X-48P|
|Cisco C1111-8P Router||SF550X-48MP|
|Cisco C1111-8PLTEEA Router with Multimode Europe and North America Advanced LTE||SG550X-24|
|Cisco C1111-8PLTELA Router with Latin America Multimode and Asia Pacific Advanced LTE||SG550X-24P|
|Cisco C1111-8PWE Router with WLAN E domain||SG550X-24MP|
|Cisco C1111-8PWB Router with WLAN B domain||SG550X-24MPP|
|Cisco C1111-8PWA Router with WLAN A domain||SG550X-48|
|Cisco C1111-8PWZ Router with WLAN Z domain||SG550X-48P|
|Cisco C1111-8PWN Router with WLAN N domain||SG550X-48MP|
|Cisco C1111-8PWQ Router with WLAN Q domain||SG350X-24|
|Cisco C1111-8PWH Router with WLAN C domain||SG350X-24PD 24-Port 2.5G PoE Stackable Managed Switch|
|Cisco C1111-8PWR Router with WLAN R domain||SG350X-24P|
|Cisco C1111-8PWF Router with WLAN K domain||SG350X-24MP|
|Cisco C1111-8PLTEEAWE Router||SG350X-48|
|Cisco C1111-8PLTEEAWB Router||SG350X-48P|
|Cisco C1111-8PLTEEAWA Router||SG350X-48MP|
|Cisco C1111-8PLTEEAWR Router||SG350X-8PMD 8-Port 2.5G PoE Stackable Managed Switch|
|Cisco C1111-8PLTELAWZ Router||SG350-8PD 8-Port 2.5G PoE Managed Switch|
|Cisco C1111-8PLTELAWN Router||Pravail 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.