1 2 3 Previous Next

Product Blog

732 posts

Network Performance Monitor (NPM) 12.4 and the Orion Platform 2018.4 are now generally available in your customer portal. For those of you subscribing to the updates in What We're Working on for NPM (Updated June 1st, 2018)  you may have noticed a line item called "Centralized Upgrades." This update will give you the first chance to experience Centralized Upgrades on your environment.


Great news this upgrade is going to be easier than ever!



Planning for Your Upgrade to 2018.4


Read the release notes and minimum system requirements prior to installation as you may be required to migrate to new server or database infrastructure. For quick reference, I have provided a consolidated list of release notes below.

Note: Customers running Windows Server 2012, 2012 R2, and SQL 2012 will be unable to upgrade to these latest releases prior to migrating to a newer Windows operating system or SQL database version. Check for the recommended Microsoft upgrade path through the upgrade center.


See more information about why these infrastructures are deprecated here: Preparing Your Upgrade to Orion Platform 2018.4 and Beyond - Deprecation & Other Important Items


SolarWinds strongly recommends that you update to Windows Server 2016 or higher and SQL Server 2016 or higher at your earliest convenience. 






Refresh your upgrade knowledge with the following upgrade planning references.



Always back up your database and if possible take a snapshot of your Orion environment.



Start Your Upgrade on the Main Polling Engine


Download any one of the latest release installers to your main polling engine.


For the screenshots that follow I'm upgrading my Orion deployment with the following setup:

  • Main Polling Engine is installed with Virtualization Manager (VMAN) 8.3 and will be upgraded to VMAN 8.3.1
    • Utilizes a SQL 2016 database
  • Three scalability engines
    • One Free Additional Polling Engine for VMAN on Windows 2012
    • One Free Additional Polling Engine for VMAN on Windows 2016
    • One HA Backup on Windows 2016


My first screen confirms my upgrade path to go from 8.3 to 8.3.1.

  • If I'm out of maintenance for a specific product, I would see indicators here first on the screen. Being out of active maintenance will prevent you from upgrading this installation to the latest, so please pay attention to the messaging here.
  • The SolarWinds installer will upgrade all of the products on this server to the versions of product that are compatible with this version of the Orion Platform for optimal stability. This may mean that you'll be upgrading more than just one product.
  • When in doubt, feel free to run the installer to see the upgrade path provided, so you can plan for your downtime. Cancelling out at the pre-flight check stage will give you all the information needed to plan ahead, without surprises and without changes to your environment.  This information can also be used for your change request before scheduling downtime for your organization.

The second step will run pre-flight checks to see if anything would prevent my upgrade from being successful on the main polling engine.

  • In case there are no blocking, warning, or informational pre-flight checks, we will proceed straight to the next step, accepting the EULA.
    • My main polling engine server and DB meet all infrastructure system requirements for the 2018.4 Orion Platform, so I am not shown any blocking pre-flight checks at this stage.
  • Pre-flight checks can block you from moving forward with your installation
    • You  may need to confirm whether you meet new infrastructure requirements (e.g. NTA 4.2.3 -> 4.4 upgrade) to proceed. Blockers will prevent you from successfully installing or upgrading, so the installer will not allow you to proceed until those issues have been resolved.
    • Warning pre-flight checks give you important information that could affect the functionality of your install after upgrade but will not prevent you from successfully installing or upgrading.
    • Informational pre-flight checks give you helpful troubleshooting information for "what if" scenarios, in case we don't have enough information to determine whether this would be an active issue for your installation.


The online installer will start to download all installers needed from the internet

  • SolarWinds recommends that you use the online installer because it will be able to auto-update and download exactly what's needed for the installation. Not only is it more efficient, but it will save you from downloading unnecessary or outdated bits.


This screen gives you an overview of next steps. The Configuration wizard will launch next, to allow you to configure database settings and website settings.

In this release, all scalability engines, including Additional Polling Engines, Additional Websites and HA Backup Servers, can be upgraded in parallel manually, using the scalability engine installer. Manual upgrades are still supported, but if you have scalability engines, please try our centralized upgrade workflow to save you time.


Follow the configuration wizard steps to completion. If you only have a main polling engine to upgrade, your installation is now complete. Log in to your SolarWinds deployment and enjoy the new features that have been built with care for your use cases.


Centralized Upgrades of the Scalability Engines

For those customers who have chosen to scale out their environment using scalability engines, such as Additional Polling Engines, HA Backup Servers or Additional Websites this is the section for you.


If you kept the "Launch Orion Web Console" checkbox checked in the final step of the Configuration Wizard, the launched web browser session will navigate you directly to the Updates Available page, where you can continue with the Centralized Upgrade workflow. If you want to open a new web browser session on a different system, you can quickly navigate to where you want to go by following these steps.


Launch the web browser and log in.

Navigate to 'My Orion Deployment' from the Settings drop-down.


Click to the UPDATES AVAILABLE tab. If this tab is not showing, that means there are no updates available for you to deploy.

Click Start, to begin the process of connecting to your scalability engines.

My environment is not experiencing any issues connecting to my scalability engines.

Bookmark this page Connection problems during an Orion Deployment upgrade - SolarWinds Worldwide, LLC. Help and Support  for future guidance on common "gotcha" scenarios, and how to handle them.

After the contact with scalability engines has been established, pre-flight checks will be run against all scalability engines

Looking at my pre-flight checks you can see that one server PRODMGMT-49 has a blocker that would prevent upgrades from occurring, mainly that it does not meet infrastructure requirements for this version of the Orion Platform.

However, my "Start Upgrade" is enabled. This is because if at least one scalability engine is eligible for upgrade, we will allow you to proceed. Only when none of the scalability engines are eligible will this button be disabled. Pay attention to servers that have blocking pre-flight checks, as you will have to manually upgrade them or move items being monitored via this scalability engine to one that is upgraded.


Clicking "Start Upgrade" begins the centralized upgrade process, first by downloading all the necessary bits to all the scalability engines in parallel. Notice how my scalability engine that was on incompatible 2012 infrastructure is not being upgraded.

Grab a coffee as the rest of your installation and configuration happens silently on each of the servers being centrally upgraded.

Oh no, an error occurred. What can you do at this point?

  • Click Retry download after troubleshooting (e.g. did the scalability engine lose connectivity to the main polling engine?)
  • RDP directly into the server using the convenient RDP link that is provided


Common scenarios to investigate:

  • Is this scalability engine set up inconsistently from the other servers? For instance, you may have Engineer's Toolset on the Web installed on this server and not on the others.
  • Do some of the installed products have dependencies on .NET 3.5? Engineer's Toolset on the Web has a dependency on .NET 3.5 to be able to upgrade. Ensure that if you have enabled .NET 3.5 and try again.
  • Check the Customer Success Center for more scenarios to help while troubleshooting.


In my case, I clicked Retry and was able to get past the issue.

My upgrade is complete! Congratulations on an upgrade well done.

Click Finish to complete your Centralized Upgrade session.


Gotchas - What to do with Unreachable Servers

If your server isn't being blocked because of incompatible infrastructure, you have an opportunity to manually upgrade that server in parallel while the rest of your environment is being centrally upgraded.


In the installation example captured below, if I were to run the installer on the Additional Website that is currently being upgraded by Centralized Upgrades, I would be blocked from running the installer on that server. However for the listed unreachable Additional Website, I can run that upgrade manually with no problem in parallel.

If you're blocked from proceeding on a manual upgrade, you would see the following. Only until you have finished the Centralized Upgrade process will you be allowed to proceed with a manual upgrade that is blocked in this fashion. For these scenarios, simply navigate to My Orion Deployment and exit out of the deployment wizard flow to cancel the centralized upgrade session.


Manual Upgrades

Manual upgrades of your deployment are still supported. If you have only one scalability engine, Centralized Upgrades may not be the fastest way to upgrade. However, if you have more, it is. This upgrade is still beneficial for those considering using manual upgrades for their deployment, and the reason is the installation and configuration wizard process can now be run in parallel. Existing customers have always known that there were some scenarios where you could run the configuration wizard in parallel across servers (e.g. same server type) and some that you could not. It took time and training to understand what scenarios those were. In this release, that limitation is lifted, and all server types can be configured in parallel.


There are times where you may need to consider falling back to manual upgrades in combination with your Centralized Upgrade. As an example, take this installation: two have completed, one has the configuration wizard in process.

If the download, installation, or configuration is taking a long time for one of your scalability engines, and you need to see more information that is only available in the client, you may consider canceling out of the Centralized Upgrade session to resume the rest of your upgrade manually. The servers that have been upgraded thus far will remain in a good spot, so you can cancel out with confidence. Proceed with this option carefully, as you will want to ensure that you have upgraded everything by the end of your scheduled downtime.

Check the My Orion Deployment page to ensure that all the servers in your Orion deployment are upgraded.



We have all been there, despite all the best intentions and all the preparation in the world, something went wrong. No worries! File a support ticket Submit a Ticket | SolarWinds Customer Portal  and start gathering diagnostics via our new web based and centralized diagnostics.


Click to the Diagnostics tab

Select all the servers in your deployment,

and click "Collect Diagnostics."

Sit back and relax as your diagnostics are centrally gathered in preparation for your support call.


Customer Experience


Early adopters and those who have participated in our release candidates have already begun to enjoy the benefits of centralized upgrades. Check out our THWACK forums for testimonials from customers just like you as they experience the new and improved "Easy Button" upgrade experience. Here's a link to one from one of our very own THWACK MVPs  The "Easy Button" has arrived with the December 2018 install of NAM (and other Solarwinds modules) If you'd like to share your upgrades with me, I'm very interested, and we'd love to see screenshots and your feedback on this new way to upgrade your SolarWinds deployment.

IPAM 4.8 has arrived and is now generally available! You can find this latest release in your Customer Portal. In recent releases, we’ve brought you integration with VMware vRealize Automation and Orchestrator and monitoring support for Amazon Web Services (AWS) Route 53 and Azure DNS. In this release, we have extended our support (yet again) to additional platforms and bring you these goodies:


Monitoring Support for Infoblox

You asked for it, you got it! This is our #1 integration feature request on THWACK®, and I’ve spoken to many of you at tech conferences about wanting us to monitor your Infoblox DHCP and DNS environments. IPAM provides valuable resources, alerting, and reporting capabilities without having to purchase add-ons, as well as a centralized management console across heterogeneous environments.


Migration to Core Custom Properties
We have migrated from product-specific custom fields to the unified custom properties designed to be simple and powerful for you to use with other Orion® Platform products. Now you can add new custom properties the same way you would for other modules and use them for IPAM entities in Reports and Alerts.

Support for More Linux Versions
We have extended DHCP and DNS support to the following Linux distributions:

    • Ubuntu 14.04
    • Ubuntu 16.04
    • Debian 9.5
    • Debian 8.6 (DHCP only)





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.

·         IPAM IP address management software[MJ1]

We’re delighted to announce the release of version 4.5 of NetFlow Traffic Analyzer (NTA)!


The latest release of SolarWinds® NetFlow Traffic Analyzer is designed to help create alerts based on application flows. In past releases, we could alert on the overall utilization of an interface and provide a view of the top talkers when the configured threshold was exceeded. In this release, you can set a threshold on the volume of a specific application in order to trigger an alert. We're making use of the Orion Platform alerting framework, so that flexibility is available to you.


You’ve outlined a small set of critical problems in multiple requests, and in this release, we’re delivering on the five most popular of these.


  • Application traffic exceeds a threshold – Alert triggered when we observe a specific application rate exceeds a user-defined threshold
  • Application traffic falls below a threshold – Alert that can provide visibility when an application “goes off the air” and stops communicating
  • Application traffic appears in the “TopN” list of applications – This alert triggers when application traffic increases suddenly relative to other applications
  • Application traffic drops from the “TopN” list of applications – Likewise, alert triggers for a sudden reduction relative to other applications
  • Flow data stops from a configured flow source – Alerts on the loss of flow instrumentation, and prompts to take action to help restore visibility


Contextual Alerting

The approach we're using to create alerts is built to guide users into a particular context—a source of flow where we see the application traffic—and then offers a simple user experience to create the alert.

To create an alert based upon any these triggers, we must first select a source of flow data as a point of reference. We can do these one of two ways.


We can visit the NTA Summary Page, and navigate to a particular source of flow data:



If the application of interest is in the TopN, we can expand it to see where this application is visible and select that source. That will take us to a detail page, which is already filtered by both application and source of the flow data.


We can also select our source of flow data directly in the Flow Navigator. We can build our alert based upon a node that reports flow, or upon a specific interface:



Once we have a context for an alert, we can select an application. If we use the "TopN Applications" resource, we have already identified both the application and the node or interface where it's visible.

Another way to arrive at this context can make use of the Flow Navigator, where we can explicitly select the application we’re interested in:




We can select either Applications, or NBAR2 Applications, to help describe the traffic. With the context now fully described, we are able to open the "Create a Flow Alert" panel and create our first alert:



At the top of the panel, we'll see the source of the flow data that we'll evaluate, and a default alert name prefix. We can customize the alert name to help make searching simpler. The severity of the alert is configurable:


For the Trigger Condition, we'll select one of the options described above. In this case, we'll select "Application Traffic exceeds Threshold," and we'll set a threshold of 50MBps on the ingress. We'll evaluate the last five minutes of traffic; this is configurable. This threshold will trigger when our traffic rate averages greater than 50MBps over the five min. time period.


Finally, we can specify one or several protocols; if we specify more than one, we'll sum the traffic volumes for all the protocols.


To create the alert, there are two options. We can select the "Create Alert" immediately, and this will simply log the alert when it triggers. Or, we can check the box to open the alert in the Advanced Alert Editor and then select "Create Alert." Selecting this option will redirect us to the last step in the "Add New Alert" wizard, where we can modify the trigger actions, reset actions, or time of day schedule.



The trigger condition is an advanced SWQL query, pre-populated with the contextual information on the source and application.


Before submitting this new alert, we'll see a message indicating whether the alert will trigger immediately.


Practical Alert Scenarios

Use the "exceeds threshold" alert for application traffic levels that average above or below the specified threshold.

Use the operation for ">" (greater than) or "<=" (less than or equal to) to determine then you can alert above or below the threshold. For example:

  • To determine when backup application traffic is running out of schedule
  • To identify large file transfers in the middle of the day
  • To identify DDOS attacks, or when Port 0 traffic is present at all

Use the <= “exceeds threshold” to help detect when an application server process goes offline and stops sending traffic.

  • The application service may have crashed
  • An intermediate connectivity problem (firewall or outage) may have reduced traffic

Use alerts related to applications appearing in—or dropping out of—the TopN can be useful for detecting sudden changes in traffic volume relative to other applications. Examples include:

  • Detecting streaming or peer-to-peer file sharing applications that are transient
  • Detecting changes in the mix of applications that usually traverse an interface


You can also set up an alert for each of your NetFlow sources to help take action if the configuration is modified, or firewall rules block flow traffic.


User Experience Improvements

This release of NTA also includes a number of small but significant improvements in the user interface to help enhance scalability and improve ease of use. Several long lists are now uniformly ordered, and we’ve changed how we label certain features to be clearer in the navigation.


Additional Resources

Check out the Release Notes, download the new release on the Customer Portal, and get additional help with the upgrade at the Success Center.


You can see these new features in action in the webcast, “Up, Down, and Gone: A Tale of Applications and Flow.”


This is an initial introduction of the traffic alerting feature. Be sure to enter additional feature requests and expanded functionality that you'd like to see with this capability!



NPM 12.4 is available today, December 4, on the Customer Portal! The release notes are a great place to get a broad overview of everything in the release. Here, I'd like to go into greater depth on the brand-new Cisco ACI support. Let’s talk a bit about how software-defined networks are different than traditional networks, what that means for monitoring, and how to get the most out of the new ACI monitoring feature.


What is SDN?


The first time I heard the term Software Defined Network, I thought it was stupid. All networks are defined by software. Software moves packets and frames, or programs the hardware that does it. Software is used to manually configure networks via CLI. Software is used to automatically configure networks with protocols like OSPF, STP, and LLDP. Networks were alreadysoftware-defined!


Whether SDN is a good name or not, it is an important concept. There’s a lot of people trying to define SDN, usually with some ulterior motive of placing themselves in a favorable position. For a slightly less biased view, check out the Wikipedia definition. The thing that stands out to me is:

SDN suggests to centralize network intelligence in one network component by disassociating the forwarding process of network packets (data plane) from the routing process (control plane).


This is a big change. In an SDN environment, network devices like routers and switches become simple devices that just move traffic at a high rate. All the intelligence is in a separate device called the controller. The controller learns how everything is connected, what connectivity applications need, and writes instructions to all of the network devices so they know how to forward traffic.


There are a ton of SDN solutions available today. The two most popular commercial solutions seem to be Cisco ACI and VMware NSX. Cisco ACI is more commonly requested by our customers (see NPM Monitor Cisco ACI and Support of a Cisco ACI networks in Network Performance Monitor compared to Vmware NSX Support), so we’ve built support for it first.


How Do I Monitor SDN?


An SDN fabric consists of a data plane and a control plane. The data plane is comprised of physical devices, Nexus switches, and, in the case of Cisco ACI, cabling. The control plane is comprised of many logical components that fit together to define what endpoints are allowed to send network traffic to each other. The modular nature of the configuration reminds me of Cisco’s MQC. To make sure your SDN environment is running well, you need to monitor both layers.


Data Plane (aka Underlay aka Infrastructure Layer)


AKA the boring stuff. This is not the glamorous part of SDN. It’s the stuff you’ve been doing for years: power supplies, fans, temperatures, CPU, RAM, and interface stats. The fact of the matter is, these things all need to function properly for your SDN environment to be performant and reliable.


The data plane for Cisco ACI environments is made up of the Cisco Nexus model line. Fortunately, NPM 12.3, the release before this one, introduced Network Insight for Nexus. This gave NPM better than ever support for this hardware.


It’s easy to set up. Navigate over to Settings (top menu bar) -> Manage Nodes -> Add Node. Add your spine switches and leaf switches as SNMP nodes. On the last step, make sure to check this box:



If you already have your switches in NPM, you can find the same checkbox when you edit a node.


You’ll be prompted for your CLI credentials. CLI is the only way some of this very important data is available, so that’s how NPM gets it. This will cover the basics like power supplies, fans, temperature sensors, CPU, RAM, and interface statistics, plus the advanced stuff like VPC.  Those of you with NCM can also get access list version control and analysis. Those of you with NTA will get flow analysis. You can check all of that out on our demo site here.


Okay, let’s get to the new interesting stuff.



Control Plane (aka Overlay aka Control Layer)


In an SDN environment, the controller has all the intelligence. This has a big impact on monitoring. Instead of polling dozens or hundreds of devices that each have their own very narrow view of the network, we can poll the controller directly. It has to know where everything is or it couldn’t control it. This means we can learn a lot from monitoring it.


This part is also easy to set up. Navigate again to Settings (top menu bar) -> Manage Nodes -> Add Node. In a Cisco ACI environment, the controller is called an APIC. Add your controller as SNMP nodes. At the bottom of the first screen you’ll see this checkbox:



Check it! If you’ve already got your APIC added, edit the node and you can find the same box to check.


Cisco strongly recommends each ACI fabric have three APICs. Since each APIC must be able to control the entire network if necessary, each APIC has a complete view of the network. Polling them all results in a lot of duplication of work and potentially duplicate alerts. You have a choice in how you approach monitoring of these devices:

  1. 1)    Add all three APICs to monitor but enable API-based ACI polling (the checkbox) for only one controller.
    1. a.    Pros: efficient for the APICs and efficient for NPM.
    2. b.    Cons: if the controller you’re doing API-based polling on goes down, you’ll see the APIC is down, but you’ll lose visibility to the control plane until you fix it or enable API-based polling for another controller.
  2. 2)    Add all three APICs to monitoring and enable API based ACI polling for all three controllers.
    1. a.    Pros: Control plane monitoring works, even if one or two of the three APICs go down.
    2. b.    Cons: NPM has to poll the same data three times. APICs have to provide the same data three times. You will get duplicate alerts and reporting data unless you’re careful to write your alerts in consideration of the duplicate data. More on this in a future post.


Our recommendation is to do #1, but either way will work.


The API-based polling runs over TLS. If you have a valid cert on your controllers, everything will add fine and you’ll be good to go. If you have a self-signed cert, you will receive a warning about it and you’ll have to accept the risk or replace it with a properly signed cert before proceeding. You do have a real cert on your APIC, right?


Once you complete the add node wizard, navigate on over to Node Details for one of your APICs with API-based polling enabled. You can click along with me right now on the Online Demo.  On the left side, you’ll see two new views: Members and Map. Let’s look at Members first.



The Members view shows all of the logical components we have discovered. This includes Tenants, Application Profiles, and EndPoint Groups. It also includes the APIC’s view of the physical components: leaf switches and spine switches.



This uses the framework’s List View, which is a polished way to deal with large lists. You can do multilevel filtering on the left, like sort, and search. The list contains the name of the component (example: Tenant3), the type of component (example: Tenant), and the distinguished name (example: uni/tn-Tenant3). On the right, we see the health score. Let’s talk about that.


Since the controller has visibility into all components and their relationships, for the first time, part of the network infrastructure is in a position to accurately assess its health. Cisco ACI does this by assigning a health score. The health score is an integer from 1 to 100, where 100 is perfectly healthy and less than 100... isn’t. The health score takes into consideration both parents and descendants in the ACI model. You can check out the exact formula here. Since health scores represent status, they’re polled at the status interval in NPM. As always, you can adjust this interval. All of this data is polled via Cortex, incidentally, our new polling framework that you previously saw powering PerfStack Real-Time Polling.


Health scores will be colored red, yellow, or green according to thresholds. There are thresholds on the APIC already for this that determine what color that score is in the APIC GUI. To stay consistent, NPM learns the thresholds from the APIC and applies those. If you customize the thresholds on the APIC, NPM will learn and apply the new threshold settings.


You can click on a health score to get the history in the PerfStack dashboard:



Thanks to this being in PerfStack, it’s easy to start correlating other metrics about the APIC, leaf switches, and spine switches. It gets more interesting when you start correlating to end node availability, latency, and other data NPM has. If you own other modules on the Orion Platform, you can correlate that data too; for example, application counters, database wait time, IOPs, logs, and all the rest. Seeing all this data normalized on the same shared timeline is powerful for troubleshooting. If a health score is in bad shape and you think the issue is on the controller, it’s time to log in to the APIC itself. The APIC can tell you what is causing the score to be what it is and has a bunch of additional ways to troubleshoot.


Returning to the sub-view menu on the left, let’s check out the Map tab.


When you first open the map, you’re only going to see the APIC in the center. To get more on the map, select the APIC. On the right side, the inspector panel will open. Here you can check the box next to related entities and press Add at the bottom to add them to the map. You can use this method to continue to spider through your ACI environment. This works well for creating a map of a small ACI environment or of a specific section of a larger ACI environment, like a tenant or an app. Once you’ve got a map you like, you can select to Save as a group in the top right. From that point forward, you can navigate to that group and press the Map tab to see the map again. Here’s an example of one I saved in my lab:



Pretty slick! One important note: the APIC GUI already has some capability to map an ACI environment. In talking to NPM users who run ACI environments, I frequently heard that they would like to grant read-only access via a common platform for folks who don’t have access to the APIC directly, like NOC engineers. This accomplishes that goal and lets you correlate and visualize with all of the other data currently available in Orion Maps.


Next Steps


To upgrade now, customers with NPM under active maintenance can head over to the Customer Portal and download NPM 12.4. Thanks to the improved Orion Installer, upgrade is faster than ever with centralized upgrade of additional polling engines. Once you’re installed, add those ACI nodes and reply here to let us know how it’s working for you!


Applying SWQL Part 2

Posted by animelov Employee Nov 13, 2018

Hi, all! Welcome back to the continuation of our Primer posts on SWQL and the Orion® SDK. In the last post, we showed how to create dashboards using SWQL queries. Now we’re going to take it one step further with some other uses for SWQL:



As with the reports, you can also add a custom SolarWinds Query Language (SWQL) query to a dashboard. If you aren’t familiar with customizing dashboards and widgets, check out these videos first:
Creating a New View
Adding and Customizing Resources


To get started, make sure you’re logged in as an admin to SolarWinds, or a user that has rights to make updates/changes to views. Once that’s confirmed, go to the page you wish to update, and go to the left-hand drawer and select “Customize Page.”

Search for “Custom Table” and drag and drop the widget onto your dashboard. There’s also “Custom Query,” and we’ll explore the advantages further down:

Select “Done Adding,” then “Done Editing” when complete. With your newly created widget, go ahead and select either “Edit” in the upper-right, or “Configure this resource” in the middle:

This should look familiar to the report writer’s interface at this point. Give this table a title, then click “Select Datasource.”

Change the Selection Method to “Advanced Database Query (SQL, SWQL)” and make sure the radio button is set to “SWQL.” Then copy/paste your query and preview results to make sure everything looks okay:

Select “Update Datasource” when complete. Just like the report writer above, you can select and format your columns. Once you’re finished, click submit, and you now have a custom table on your dashboard!


Note: The Host Name column being blank isn’t an error, these machines are not associated to a host.  We’ll explore formatting in a later post to show these as “N/A” instead.


Now, let’s try the custom query instead. With the “Custom Query” widget, you don’t have as many options in formatting, but it gives you two distinct advantages: the ability to paginate, and the ability to add searches. Pagination will be very important for larger lists, not only for cleanliness, but also for load times on the page you’re viewing, by restricting to X number of results at a time.


Again, go to the left-hand drawer and select “Customize Page,” then “Add Widget.” This time, search for “Custom Query” and drag/drop this widget to your dashboard:

Now, select “Edit” in the upper-right corner of the widget:

Notice here, you only get a box where “Select Datasource” would normally be. Go ahead and copy/paste your query in here, but since you don’t get the option of selecting the order of the columns, make sure your columns in the select statement are in the order you want them in. For example, with our query:
select OAA.Displayname, OAA.Status, OAA.Node.Caption, OAA.Node.VirtualMachine.Host.HostName from Orion.APM.Application OAA

Displayname” will be the first column, “Status” will be the second column, and so forth. So now that we have this:

That will result in a widget that looks like this:

Notice the “Page 1 of 2” at the bottom? This will help reduce clutter on your dashboards by keeping the list neat and tidy, and at the same time help with page loads, since we’re restricting to only five results. Another cool feature is the “Search” function. Edit the widget again, and this time check the “Enable Search” box:

Now you have another box to insert your query, and a note about adding a where clause for the search string. When we’re finished, we’ll have a search box on the widget page, and whatever you put in that box will go into the ${SEARCH_STRING} variable. This will change our query to add the where clause. In this case, we’re going to search on the Application name, which is our first column:


select OAA.Displayname, OAA.Status, OAA.Node.Caption, OAA.Node.VirtualMachine.Host.HostName from Orion.APM.Application OAA WHERE OAA.DisplayName like ‘%${SEARCH_STRING}%’


The keen-eyed individuals will notice we added just a little bit more here. In SWQL, if you want to do a wildcard match instead of an exact match, you use the word “like” instead of “=”. Then, you use the percent character (%) to denote a wildcard, not an asterisk (*). Finally, in SWQL you always use single quotes for strings, never double quotes. Let’s put that in our search box:

And now we have a search box!

To test, let’s search on IIS and see what we get:

There we go! Remember, this is just an application example, you can use this for anything else that you’re collecting in the product. For more examples, check out my other post for searching on a Port Description in User Device Tracker (UDT): https://thwack.solarwinds.com/docs/DOC-192885



That’s it for now! Stay tuned for future posts on formatting SWQL queries in these reports!

SQL Server upgrades are a pain, I know.


And boring, too. It’s not very exciting to watch a progress bar.


Many people put off upgrading SQL Server. They wait for a business reason or an important security patch. Or, as was the case historically, they wait for the first service pack. After all, if it ain’t broke, don’t touch it.


I’m here today to tell you those days are over.


No longer can you sit back and allow systems and applications to lag behind with regards to patches and upgrades. You must stay current. Allowing applications to be more than one major version behind puts you, and your systems, at greater risk for security threats than ever before.


Microsoft has made it easier to upgrade and patch SQL Server. They’ve removed service packs, opting instead for cumulative updates. By shifting to a model that is similar to continuous deployment, Microsoft is able to deliver features, performance improvements, and security enhancements at a faster rate than ever before.


So, if you are waiting for SQL Server 2017 SP1, you’ll be waiting forever.


Don’t wait. Get started on upgrading SQL Server to the latest version today.


Let me help you understand just a few of the reasons why upgrading SQL Server is right for you.


Reasons for Upgrading SQL Server

As I mentioned before, it’s just common sense to stay current with the latest version of SQL Server. Microsoft has built tools like the Database Migration Assistant to help make upgrades easy. Applying cumulative updates has also been simplified. And because Microsoft hosts millions of database workloads inside of Azure SQL Database, you can be assured that these updates have been tested thoroughly.


Here’s a handful of the features available, out of the box, when you upgrade to the latest version of SQL Server.


Automatic database tuning – The ability for the database engine to identify and fix performance problems.


Adaptive query processing – While processing the execution plan, SQL Server will adapt query plans as necessary, essentially tuning itself instead of reusing the same plan.


Data security and privacy featuresAlways Encrypted, Dynamic Data Masking, Row Level Security, Data Discovery and Classification, and Vulnerability Assessment are all new, and all awesome.


Those are just a handful of the improvements. You will also find things like faster DBCC CHECKDB, improved backup security, and a new cardinality estimator. All those are great features worth your time for upgrading.


But there’s one more thing: the Orion® Platform.


See, we’ve been busy refactoring the Orion Platform to take advantage of newer SQL Server features.


Reasons for Upgrading Your Orion Installation

When I’m at an event performing demos, I am surprised how many customers haven’t upgraded to the latest version of the Orion Platform. Of course, I understand the many reasons why upgrades are put on the back burner.


I’m here today to help you understand that there’s more to the latest Orion version than a few fancy screens.


By using columnstore indexes, we have reduced the size of the Orion database (up to 33% less space), the amount of time it takes to perform maintenance (up to 6x faster on average), and the amount of time to retrieve data (up to 10x faster). That’s a lot of performance gains.


Table partitioning allows Log Manager for Orion to scale, accommodating multiple log sources, and the ability to quickly display all logs in time sequential order. As anyone that has had to analyze logs will tell you, it’s important to be able to quickly see all events in the exact order they occurred.


Also, in-memory OLTP helps products that leverage the Orion Platform achieve a high rate of concurrency, accelerating performance and scalability.


Those features sound great, but don’t just take my word for it. You should read about the SQL Server features being used by NetFlow Traffic Analyzer (NTA) over at this FAQ page.


Now, at the bottom of that page, I want to call out something else that you will find interesting…


“You can install your NTA Flow Storage database and your Orion database in the same instance of MS SQL, provided that instance is an MS SQL 2016 SP1 or later version.”


That’s right, upgrading to the latest version of NTA allows you to consolidate your SolarWinds footprint. For customers paying by the core for SQL Server licensing, this alone should motivate you to upgrade.


I’ll make it easy for you: here’s a link to help you get started. Also, here’s the official upgrade guide located on our Customer Success Center.


I’ve also written some other in-depth posts about tips and tricks on upgrading SQL Server. Have a look—I believe you’ll find the information useful.



At the end of the day, we want the same thing that any company would want: happy customers.


By upgrading to the latest version of SQL Server, and then the Orion Platform, our customers can see benefits immediately. Not just in performance, but in your wallet.


Continuous improvement is the world in which we live now. Stop thinking of upgrades as a chore or a task to get past. Upgrade because you want to, not because you have to.


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 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.







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.




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.”


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!




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.

As awesome as SolarWinds applications can be at helping avoid a network crisis, sometimes disaster strikes closer to home: in the Orion® Platform itself. You come in to work one morning and click on the web page, only to see an unhandled exception, or you realize you haven’t seen an alert in a suspiciously long time, or you plan an upgrade expecting everything to go smoothly and find yourself stumped by a configuration wizard error. While our awesome support folks are here to help you get past any trouble you might run into, wouldn’t it be great if you had a way to check the health of your SolarWinds environment to prevent a catastrophe?

Well, good news: now you do! Introducing the Orion Health page, designed to help you keep your SolarWinds environment humming along trouble-free. You can go to Settings -> All Settings -> High Availability Deployment Summary (found in the Product Specific Settings section). Once there, you will see a tab called Deployment Health (and don’t worry, even if you don’t use our High Availability product, you still have these options).


This page has over 70 checks created from analyzing the most common reasons why customers call us. We cover everything from database maintenance to disk space. The best part is, you don’t have to remember to come to this page and run the server health checks regularly—they will run every night along with our regularly scheduled database maintenance. We run specific tests against each server in your deployment. Got an additional web server? A scalability engine? A standby server? We got you covered!



Of course, every environment is different, and we know that some tests might not apply to everyone. For example, we’ll warn you that if your SQL Server is on a VM, that might not be the best setup.  Sometimes resource-intensive applications like SQL don’t play well with shared resources. But if you know that your VM is a beast and can handle whatever we can throw at it, you can just silence that particular check:

You won’t see it again unless you un-silence it, so your daily view will be only the tests you care about.


There’s a KB for that!

So now you’re using the health page to keep everything copacetic, and you find a failure that you’re not quite sure what to do with.  Well, we’ve got a whole database full of Knowledge Base articles right at your fingertips! Just click on the arrow at the end of the row with the test on it, and a panel will pop up with a description of the test and a link to an article with more info.



Now that you have this tool at your fingertips, remember that we always welcome your feedback. Think there’s something we could test for that we don’t? Something that needs to be tweaked? Let us know and we’ll be happy to take a look!

Hi, all! Welcome back to the continuation of our Primer posts on SWQL and the Orion® SDK. In the last post, we established how to create a query, and how to link tables together to get useful information. In this post, we’re going to discuss how to apply these to your Orion Platform products.

If you don’t feel entirely comfortable creating a query, I highly encourage you to read over the last post. It serves as a foundation for today’s discussion.



The first and most obvious application for SWQL queries is generating Orion reports in the web-based report writer. To start, go to Reports à All Reports, then select “Manage Reports” in the upper right corner:



From here, click on “Create New Report”:



If this is your first time creating any report, you will see a nice splash page on how to create reports. I highly recommend you read it over to get an idea of the process, and when you’re finished, go ahead and close to proceed with the remaining steps.


The first page you see when you create a report is Add Content. For what we’re doing, there really are only two options, Custom Chart and Custom Table. Since we’re going to use the example from the previous post, let’s select the “Custom Table” option.



Once selected, you are asked to add your data source. This is where our SWQL magic comes into play; change the Selection Method from “Dynamic Query Builder” to “Advanced Database Query (SQL, SWQL)”:



Make sure the radio button is set to “SWQL” so Orion knows which language to construct from. From here, let’s copy and paste our query from the previous post into the big box. Then click on “Preview Results” to make sure everything is working correctly. Note: this will not show you all results, just a small selection:



Once that’s complete, click “Add to Layout,” which will automatically send you to the custom table formatting table. Here you can add the columns from your query into the report:




Now that your columns are added, you’ll see the table layout section. Use the dotted icons to arrange the columns in any order you want (1). You can also expand on the column to change their name (2) to something friendlier, such as “System Name” instead of “Caption” (3):



Once you’re finished, click “Submit” to finish the table. If you wish to add more tables, or if you charted something, you can add more resources to the page. Otherwise, you can finish your report as you would normally.


That wraps it up for now. Next time we’ll continue exploring how to apply SWQL queries into widgets in the dashboard. Thanks for reading!

Doing more with less seems to be a staple of working in IT today.  Part of that also includes doing more with the existing tools at your disposal or adding tools to make your job easier, giving you back your well-earned free time.  For IT professionals, getting the information into a network monitoring software (NMS) solution is only the first step in the battle.  Deciding how to work with that information is the next phase in your evolution as a monitoring professional.


It's no secret that I was a customer before I come to work for SolarWinds.  As a former customer, I tried my best to make sure that my monitoring solution did as much of the heavy lifting for my organization as possible.  In my eyes, what good was a system that just alerted me to problems without actively trying to correct those problems?  Were the metrics important to specific teams being shown in the proper light to guide business decisions?  Were our help desk and IT teams properly informed about the state of the infrastructure? These are just a few of the questions that I asked myself on a near daily basis.  Making tweaks and updates to the NMS became a process of care and feeding for the solution.  Thankfully, I had the THWACK® community and the plethora of content therein to help guide me, but every environment is different.  I often thought it would be nice to be able to get first-hand information and ask questions of the experts about my situation.


I've spoken at multiple SolarWinds User Groups (SWUGs) about the ways to help optimize and scale out your build, streamline your support and monitoring processes, isolate and pinpoint the root cause of issues, eliminate noise in your alerting, and leverage the data collected to make informed decisions.  Any one of these can help you do more with what you already have.  The more feedback we get from the community, the more resources we can provide to give you back your weekends.  We've listened, and that's part of what makes THWACKcamp so epic.


This year, THWACKcamp is packed full of knowledge bombs that can help you do your job better, more efficiently, and with less stress.


If you are thinking about working towards automating your infrastructure, take what you've learned and leverage the SolarWinds Orion API with “There's an API for That: Introduction to the SolarWinds Orion SDK.”  We are even including our code samples (here, here, and here) so that you can play along with the home game.


There's an API for That: Introduction to the SolarWinds Orion SDK

Repetitive tasks are boring and repetitive. Why do we have computer systems if not to make our lives easier? In this session, learn why we want to leverage the SolarWinds® Orion API to do just that with me and fellow THWACK MVPs Leon Adato and Zack Mutchler.


Do you have a large or growing deployment and are worried about optimizing your build?  There's a session just on “Optimizing Orion.”

Optimizing Orion

In this session, we will help you understand how to optimize your Orion® Platform. We will discuss topics such as when to know if you should scale up or scale out, and how to identify issues with your current Orion installation.


Are you struggling from beneath a pile of unnecessary alerts and are trying to find the light?  Why not have your alerts work for you, instead of against you?  “Alerts, How I Hate Thee” is the session for you.

Alerts, How I Hate Thee

Many IT professionals believe if you can't get an alert when something is going wrong, why monitor at all? Yet alerting is also seen as a curse, a source of constant interruptions, false alarms, and “noise.” In reality, it can be so much better. Well-crafted alerts based on insightful monitoring are a benefit to the business and a gift to the recipient, saving hours of investigation and thousands of dollars. Whether alerts are a blessing or a curse depends largely on their design and implementation (more so than any specific monitoring tool or technique) and thankfully, good design can be taught and learned. In this session, we'll take a brief tour of the alerting hall of horrors, and then look at real-world, vendor-agnostic techniques to make alerts meaningful, effective, valuable, and actionable.


Is it time to get the biggest bang for your bits with your NMS, it's probably useful to take peruse the goodness during “Tips & Tricks: Thinking Outside the Box

Tips & Tricks: Thinking Outside the Box

Making its third round at THWACKcamp, this popular session covers the tips and tricks of our beloved SolarWinds products that are a way of life for me and Head Geek Destiny Bertucci. Combined forces makes for some great tips and tricks that help you to think outside of the box for your day-to-day monitoring needs. There are always ways to create solutions with just a little tweaking to make your SolarWinds products be the highlight in any organization.


The best part about a THWACKcamp session?  They are completely free for everyone – you just need to sign up, select your sessions, and then sit back and absorb all the nerdy goodness online. Plus, if you watch live, you can join the chat and ask questions of the experts while the session is happening. What are you waiting for?  Sign up now!

As some organizations start to either move workloads to the cloud, or as they build new apps and services natively within the cloud, the number of hybrid deployments and environments are increasing exponentially. In these hybrid environments, it’s important to remember how critical it can be to retain a single pane of glass, allowing for visibility into your applications and infrastructure.


With the recent release of Server & Application Monitor v6.7 (SAM), we’ve built in support for monitoring containers for Docker, Mesos, and Kubernetes, giving you visibility infrastructure wide into physical, virtual, cloud, and now container infrastructure.  Check out SAM’s product page to see all of SAMs features and supported systems and applications.  As cloud services and cloud infrastructure continues to grow and see more adoption, Server & Application Monitor needs to grow with it. In this post, we’ll discuss some of the ways we’re supporting this growth, as we highlight several new additions to support Microsoft Azure PaaS services. We’ll dive deeply into three of these new additions below. And of course, as always, please let us know any additional content you’d like to see SAM monitor.   To begin these template and others, SAM is can be download here.


The three new templates I am going to cover today for Azure include:

  • Azure App Service
  • Azure SQL Database
  • Azure Event Hub


For all three of these templates, be sure to install a couple of PowerShell modules on the system that SAM is installed, allowing you to leverage the following PowerShell commands:

  • Install-Module -Name Azure
  • Install-Module -Name AzureRM


Azure App Service:

Application Template can be downloaded here - Microsoft Azure App Service.apm-template



  1. To connect with your Azure account, the following parameters are required:

     subcriptionID,ApplicationID,TenantID, Secret Key, Application Name

     Note: Azure App to monitor, with its name and ID, should have role set as 'contributor or Reader' in the Azure access control.

    2. Application name for which metrics will be calculated.

    3. Time interval for which data has to be fetched (in hours).

    4. PowerShell version supported 5.1 or above.


Script Argument:

  • Login credential to access Azure Portal. Azure details have to be passed in script arguments as per prerequisite #2.


             <SubscriptionID>,<TenantID>,<ApplicationID>,secretKey=<Enter SecretKey>,<ApplicationName>,TimeRange=<Time in hrs>

  • The ApplicationID with which you are making a connection to the Azure portal (as mentioned in Credential/Prerequisites) must be registered in Azure Active Directory as a contributor role for the monitored application.

        Reference link: https://support.solarwinds.com/Success_Center/Server_Application_Monitor_(SAM)/Knowledgebase_Articles/Add_an_Azure_Active_Directory_app_for_cloud_monitoring_in_the_Orion_Platform


Portions of this document were originally created by and are excerpted from the following sources:






  • Average number of bytes sent

      This monitor provides the average number of bytes sent for the given app.

      Unit: MB (Mega Bytes)

  • Total number of 2xx requests

      This monitor provides the count of requests resulting in an HTTP status code >= 200 but < 300 for the given app.

      Unit: Count

  • Total number of 3xx requests

      This monitor provides the count of requests resulting in an HTTP status code >= 300 but < 400 for the given app.

      Unit: Count

  • Total number of 401 requests

      This monitor provides the count of requests resulting in HTTP 401 status code for the given app.

      Unit: Count

  • Total number of 403 requests

      This monitor provides the count of requests resulting in HTTP 403 status code for the given app.

      Unit: Count

  • Total number of 404 requests

      This monitor provides the count of requests resulting in HTTP 404 status code for the given app.

      Unit: Count

  • Total number of 406 requests

      This monitor provides the count of requests resulting in HTTP 406 status code for the given app.

      Unit: Count

  • Total number of 4xx requests

      This monitor provides the count of requests resulting in an HTTP status code >= 400 but < 500 for the given app.

      Unit: Count

  • Total number of 5xx requests

      This monitor provides the count of requests resulting in an HTTP status code >= 500 but < 600 for the given app.

      Unit: Count

  • Total number of requests served by the app

      This monitor provides the total number of requests regardless of their resulting HTTP status code for the given app.

      Unit: Count

  • Average number of bytes received

      This monitor provides the average number of bytes received for the given app.

      Unit: MB (Mega Bytes)

  • Average memory used

      This monitor provides the average amount of memory in MBs used by the given app.

      Unit: MB (Mega Bytes)

  • Average response time

      This monitor provides the average time taken for the app to serve requests in milliseconds (ms).

      Unit: MS (Milliseconds)



Detailed troubleshooting steps (common for template):

  • Check that the PowerShell version is 5.1 or more and the Azure module is installed on the system where the template will run.
  • Template uses PowerShell components; script should run with administrator privilege.

Be sure to detail troubleshooting steps (specific for components).

  • Components connect with Azure using service principal authentication for which application has to be created at the Azure portal. See below link:


  • Provide Azure IAM permission to the application, which was created in the last step. See below link:


  • Script fetch data based on time range given in last script arguments. By default, script fetch data for the past hour. While giving the time range, make sure the data is available for the metric at that time, otherwise the component will be unable to fetch the data.


Azure SQL Database:

Application Template can be downloaded here: Microsoft Azure SQL Database.apm-template



  1. To connect with your Azure account, the following parameter is required: subcriptionID, ApplicationID, TenantID, Secret Key.

Note: Any Azure App (with its name and ID) having role as 'Read Only'.

    2. SQL Server Database name for which metrics have to be calculated.

    3. Time interval for which data has to be fetched (in hours).

    4. PowerShell version 5.0 or later.



  1. Login credential to access your Azure Portal. This has to be passed as script arguments per prerequisite #2, as listed above. e.g. <subcriptionID>, <TenantID>, <ApplicationID>, value=<Secret Key>, <Application Name>, value=<Time Interval>, <Database Name>
  2. Windows Administrator on the machine where template would be running against.    


Portions of this document were originally created by and are excerpted from the following sources:





  • Blocked Connections

      This metric provides the average number of firewall blocked connections established for the given SQL database during the time period specified as the polling frequency.

      Unit: Count

  • Failed Connections

      This monitor provides the average number of failed connections established for the given SQL database during the time period specified as the polling frequency.

      Unit: Count

  • Successful Connections

      This metric provides the average number of successful connections established for the given SQL database during the time period specified as the polling frequency.

      Unit: Count

  • Deadlocks

      This metric provides the average number of deadlocks established for the given SQL database during the time period specified as the polling frequency.

      Unit: Count

  • Database throughput units (DTU) limit

      This metric provides the average database throughput limit in units for the given SQL database during the time period specified as the polling frequency.

      Unit: Count

  • Database throughput units (DTU) used

      This metric provides the average database throughput units used for the given SQL database during the time period specified as the polling frequency.

      Unit: Count

  • Sessions percentage

      This metric provides the average percentage of available sessions used for the given SQL database during the time period specified as the polling frequency.

      Unit: Percent

  • Database size percentage

      This metric provides the average percentage of storage used for the given SQL database during the time period specified as the polling frequency.

      Unit: Percent

  • Total database size

      This metric provides the average for the total database size for the given SQL database during the time period specified as the polling frequency.

      Unit: Megabytes

  • Workers percentage

      This metric provides the average percentage of available workers used for the given SQL database during the time period specified as the polling frequency.

      Unit: Percent

  • Average CPU utilization

      This metric provides the average percent CPU used for the given SQL database during the time period specified as the polling frequency.

      Unit: Percent

  • Average IO utilization

      This metric provides the average percentage of data IO used for the given SQL database during the time period specified as the polling frequency.

      Unit: Percent

  • Average log utilization

      This metric provides the average percentage of log IO used for the given SQL database during the time period specified as the polling frequency.

      Unit: Percent

  • In-Memory OLTP storage percent

      This monitor provides the average In-Memory OLTP (Online Transaction Processing) storage percent for the given SQL database during the time period specified as the polling frequency.

      Unit: Percent

  • Database throughput unit (DTU) percentage

      This metric provides the average percentage of database throughput units used for the given SQL database during the time period specified as the polling frequency.

      Unit: Percent


Azure Event Hub:

Application Template can be downloaded from here: Microsoft Azure Event Hub Namespace.apm-template



  1. To connect with your Azure account, the following parameters are required: subcriptionID, ApplicationID, TenantID, Secret Key, Application Name

Note: Any Azure App (with its name and ID) having role as 'Read Only'.


  1. Namespace for which metrics have to be calculated.
  2. Time interval for which data has to be fetched (in hours).
  1. PowerShell version 5.0 or later.



  1. Login credential to access the Azure Portal. This has to be passed as script arguments per prerequisite #2, listed above. e.g. < subcriptionID>, < TenantID>, < ApplicationID>, value=<Secret Key>, <Application Name>, value=<Time Interval>, <Application Name>
  2. Windows Administrator on the machine where template would be running against.    


Portions of this document were originally created by and are excerpted from the following sources:





  • Archive backlog messages

      This monitor provides total Archive messages in backlog for the given namespace via PowerShell cmd-let.

      Unit: Count

  • Archive message throughput

      This monitor provides total Event Hub archived message throughput for the given namespace via PowerShell cmd-let.

      Unit: Bytes

  • Archive messages

      This monitor provides total Event Hub archived messages for the given namespace via PowerShell cmd-let.

      Unit: Count

  • Incoming Bytes

      This monitor provides the total Event Hub incoming message throughput for the given namespace via PowerShell cmd-let.

      Unit: Bytes

  • Outgoing bytes

      This monitor provides the total Event Hub outgoing message throughput for the given namespace via PowerShell cmd-let.

      Unit: Bytes

  • Average Disk Seconds per Write

      Average Disk Seconds per Write is the average time of a write of data to the disk.

  • Incoming Messages

      This monitor provides the total incoming messages for the given namespace via PowerShell cmd-let.

      Unit: Count

  • Incoming Requests

      This monitor provides the Total incoming send requests for the given namespace via PowerShell cmd-let.

      Unit: Count

  • Internal Server Errors

      This monitor provides the Total internal server errors for the given namespace via PowerShell cmd-let.

      Unit: Count

  • Other Errors

      This monitor provides the total failed requests for the given namespace via PowerShell cmd-let.

      Unit: Count

  • Outgoing Messages

      This monitor provides the total outgoing messages for the given namespace via PowerShell cmd-let.

      Unit: Count

  • Successful Requests

      This monitor provides the total successful requests for the given namespace via PowerShell cmd-let.

      Unit: Count

  • Server Busy Errors

      This monitor provides the Total server busy errors for the given namespace via PowerShell cmd-let.

      Unit: Count



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.

I’m happy to announce General Availability of Storage Resource Monitor 6.7. This release continues the momentum of supporting arrays that you all requested on THWACK®. It also comes along with new functionality both that you all have asked for as well as some that we think you’ll be surprised by and excited to check out. So, without further ado, why don’t we take a look at what’s new? (Note: that rhymed)


(Also, don’t forget to check out the SRM 6.7 Release Notes for more information about installing, upgrading, and new fixes.)


New Array Support

As you have probably come to expect, the aforementioned support includes all the standard features you know and love: capacity utilization and forecasting, performance monitoring, end-to-end mapping in AppStack™, integrated performance troubleshooting in PerfStack™, and Hardware Health. Now, as of SRM 6.7, we support the following devices:


  • Huawei OceanStor v3 Series
  • Huawei OceanStor v5 Series
  • Huawei Dorado V3 Series


What’s that? You want to see the screenshots to prove it? We can provide that.


Summary View


Block Storage


File Storage


Hardware Health (don’t worry about the critical state – we’re on it.)


New Hardware Health Support

What if you were able to extend the previous screenshot to arrays that you’re already using SRM to monitor? And you were able to see details on fans, power supplies, batteries, and more? With SRM 6.7 you can do that for the following array vendors and types:


  • EMC Isilon v8
  • NetApp


How great is that? And yes, of course, here’s your screenshot:




Support for GTP Format Partitions

This is something we’ve heard from some of you recently. And you all have discussed it on THWACK as well. So, as normal, ask and you shall receive. With SRM 6.7, we have added support for GPT drives on Windows Server 2008 and later. Here’s a screenshot of what it’s going to look like when you’re selecting what to monitor (after that step, it’s going to be the same great experience you’ve come to expect from your MBR partitions):

Support for Storage in Orion Maps

This feature comes with a tremendous amount of capability. So much so, that we have dedicated blog posts on it. But before I link you to that, I’ll write a quick note about what it means for you and SRM.


Starting with our newest releases (which include SRM 6.7), Orion® Maps are now going to include data all the way down to your storage environment. That’s huge. Say, for example, if all you think (and want to think) about all day is storage, you can now open an Orion Maps view from your storage device screen and sit back as a map is built for you that shows you what VMs sit on top of that storage. Automatically—you don’t have to do a thing. How great is that? What you do with that information (read “who you go after”) is up to you.


And, you want a screenshot? Forget screenshots. This one is animated:




Again, there is a ton here to cover, so I’ll leave you with the short taste above and this link to a wonderfully written post on the topic.


What’s Next

That’s it for the meaty functionality of SRM 6.7. There was a lot there and we’re excited to share it all with you.


If you don’t see what you’re looking for, head over to our What We’re Working On post to see what our storage team is already working on for our next releases. If you don’t see what you want there, make sure to add it to the Storage Manager (Storage Profiler) Feature Requests page.


And of course, we want to know what you think—just let it be known below in the comments.


Disclaimer: 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.

I am pleased and excited to announce the latest addition to the SolarWinds product family on the Orion® Platform, Server Configuration Monitor or SCM. For those of your that are familiar with our Network Configuration Manager product or NCM, this new product is its sibling with a focus on systems and applications.

With this new product, SolarWinds continues to deliver on our unexpected simplicity promise of building simple, powerful, and affordable products.  SCM, built on the Orion Platform, is designed to enable you to capture, visualize, and understand changes in your environment in near real-time.

With this first version, we are focused on Windows systems and enabling customers to version and diff the following elements.

  • Hardware
  • Software
  • Registry
  • Files
  • Microsoft IIS


While we have already delivered v1, the team is hard at work to continue to advance and expand this product as outlined in our “What We Are Working On” post.  SCM is licensed by nodes, a simple-to-understand model, and pricing is affordable to many.  Let’s walk through a couple of use cases of how you could use the product.


Web Application Outage:

At the same time that you receive an alert from Server & Application Monitor indicating a critical web application is down, you also begin to receive calls from users indicating they cannot access it.


Where do you start investigation to determine where the problem lies? 

  • Is this a networking problem?
  • Is the hardware having a problem?
  • Is this a storage or database problem?
  • Is this application running on your virtual platform and is that having an issue?


While investigating each of these areas, the clock is ticking and you are getting more and more calls. 

Using the SolarWinds® PerfStack dashboard for a real-time view into multiple different metrics and parameters, as highlighted in the below screenshot, I can see that right before the web application went down, a configuration change was detected.



In the data explorer, I click on the web.config link and I am immediately taken to a comparison or “diff” page showing me what changed here.  As you can see, someone went in and made some edits to this config file and now the XML structure is broken, which took down your web application.  Now you can quickly remote desktop into that machine and change this back, save the file, and get the web application back up and operational.  So, what may have taken 30-60 minutes to investigate the infrastructure and root cause was isolated and addressed typically in minutes with SCM.



Let’s briefly touch on a couple of other use cases for Server Configuration Monitor.

  • Unauthorized Software
  • Malware Security Incident
  • Hardware Change



So how does it work? It all depends on what you want to monitor. If you are only interested in hardware and software versioning, we can do this without an agent. However, if you want to monitor files for changes, registry, or Microsoft IIS, then you will need to deploy the Orion Agent onto this machine. If you already have the Orion Agent deployed on your machine (for example, for monitoring in SAM) SCM is an add-in package in the Orion Agent that just needs to be enabled. The key point I am making here is this is not a separate agent.




Don't see what you are looking for here?


Visit the SolarWinds Server Configuration Monitor forum.

Check out the What We're Working On for SolarWinds Server Configuration Monitor post to see what our dedicated team is already looking at.

If you don't see everything you've been wishing for there, add it to the SolarWinds SCM Feature Requests.


We are excited to get this out there and begin to gather input and feedback. Don’t forget you can quickly and easily install a free, fully featured 30-day trial to kick the tires yourself.


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.

Upgrading SolarWinds Orion Platform Products is Amazing

By Destiny Bertucci



          I know what you’re thinking right now, “She's out of her darn MIND!” Bear with me for a moment here. I’ve seen a lot of failed upgrades and pushback on upgrading systems to newer OS and application versions. However, I’ve seen more, even smoother upgrades in the past few years that have allowed me to want to make sure everyone has the best experience possible when upgrading.This means I’ve gathered information that can help you be more knowledgeable about why you should upgrade and to get the best features available all while achieving more secure options for your environment. Without further ado, let’s dive in.


          I’d like to start with some necessary information to help you prepare for upgrading, no matter what level you are currently on. I can help guide you to a better environment with the SolarWinds® Orion® Platform while maintaining proper control on how it should be done to help sidestep some “gotcha” moments.

  1. You must know what version you are on, period. When I say that, I mean I’d like for you to have a notepad or an Excel® sheet that allows you to have all the info on your environment readily available. I’ve attached the one I currently use while managing my environments.
  2. You’ll need to know where to find your version and upgrade path:
  3. If you are on 12.0 or above, use this: https://support.solarwinds.com/Success_Center/Orion_Platform/Orion_Documentation/SolarWinds_Orion_Installer
  4. If you are below 12.0, please use the following: https://customerportal.solarwinds.com/support/product-upgrade-advisor
  5. Check out Windows® version support for each level of SolarWinds Orion Platform products:  https://support.solarwinds.com/Success_Center/Orion_Platform/Knowledgebase_Articles/Windows_Server_2012_2016_and_SQL_Server_2012_2014_2016_and_2017_Support
  6. My favorite information is the migration guide. Because sometimes when you’re behind in the upgrade cycles, you realize you need a complete overhaul of your environment. Again, perfectly fine! Sometimes it’s even best to migrate when upgrading because you can stay up to date more easily on a new platform. So, this guide is one I keep near and dear to my heart: https://support.solarwinds.com/Success_Center/Network_Performance_Monitor_(NPM)/NPM_Documentation/Migration_Guide
  7. DBAs love information about the types of databases needed and/or used. Here’s a link to help everyone on your environment team be aware of the end game with databases: https://support.solarwinds.com/Success_Center/Orion_Platform/Knowledgebase_Articles/Databases_used_by_SolarWinds_modules
  8. SQL Server® requirements: https://support.solarwinds.com/Success_Center/Orion_Platform/Knowledgebase_Articles/Databases_used_by_SolarWinds_modules
  9. Port requirements: https://support.solarwinds.com/Success_Center/Network_Automation_Manager/NAM_Install_Guide/030/020
  10. Look up each module’s requirements, so you’re creating an environment that lasts and is a pleasant environment for users to use. There is nothing worse than waiting for the page to load because the database is underpowered OR the NetFlow database is underpowered for the number of flows you are using. Please acquaint yourself with the SolarWinds Customer Success Center and use it to find the system requirements you need. 
  11. Here is an excellent link from our awesome community members on in-place upgrades for SQL: https://thwack.solarwinds.com/message/398951#398951


           Now that you have gathered the information that you need, let’s talk about why you would want to upgrade. With the ability to use configurations within your network devices to visualize data, it’s vital to bring in these devices and use them to stay ahead of issues better and even solve some issues you may not have seen before.


          What in the world is she talking about now? Well, how about being able to see interface config snippets for your Cisco® devices on the interface details page? Or visualizing a switch stack for full redundancy, and using NetPath network path analysis  to break through your firewall to show you connection points from end to end? One major reason you may want to upgrade is to simplify your environment’s “break-down” moments. 


           SolarWinds has been working one-on-one with IT groups in all departments to understand and work to solve for their frustrations. Being able to visualize those virtual port channel bundles, for instance. Instead of waiting for an alert, it would be nice to shake out your monitoring and management environment to allow yourself to see clearly and make decisions based on your baselines that match your unique setup.


          Security-wise, let’s be honest… if you’re on an unsupported version of Windows or SQL Server, that’s a security issue, big time. If they’re not patchable, they are NOT on my environment. Security should be a focus for you, especially for older versions of .NET. Let’s get our heads in the game and start visualizing these upgrades and making them happen, you know, for security’s sake and all.

          All the data I provided here SHOULD allow you to have a successful upgrade in your future. If you have any suggestions for upgrading, please drop me a line!




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.