Last week, we released version 6.0.1 of Log & Event Manager. Normally we don't make too much noise about service releases (minor dot releases) 'round these parts, but this time we decided to make an exception. We packed a lot of security enhancements and customer requests into this release that you should definitely be aware of.


Enhanced Security Features

  • Removal of several flagged "vulnerabilities" on the LEM appliance: We continuously monitor security scans and while rarely (dare I say, almost never?) has there been an issue without a mitigation (like ShellShockfor example), we do still try to make sure we reduce and ideally eliminate any vulnerability scans from flagging the LEM appliance in any way. With this release, we've cleaned up all known security scan flags except the visibility of the Tomcat error page which we're looking into for a future release, and a couple of certificate triggers which are expected and would be resolved by using a CA-signed cert.
  • Better support for using signed certs: We had some customers use the ability to sign and re-upload certs for the LEM console, but there were some cases where it didn't work quite right. We shored up our support for certs and things should be much improved.
  • Improved enforcement for password storage for connectors: some connectors require storing username/password credentials (connectors that use a database to retrieve log data, for example) so we've beefed up encryption and version enforcement for storage of those passwords. Once you upgrade your 6.0.1 appliance and console, you'll need to also upgrade any agents that might have one of these connectors configured (or where you'll configure one going forward).

And the big one...

  • Named user access and TLS support for reports: our database has been encrypted since version 5.6 (and even before that has always been limited access), but using JDBC access and a fixed username was cause for concern for some folks. We've migrated to using LEM users (including AD users) for reports instead, and optionally allowing you to enable TLS connectivity.
    • There's a new "reports" role in the LEM console that you can assign if you have users that shouldn't have access to real-time data, but do need access to historical data. In addition, admin and auditor roles also have reporting access (but not monitor users).
    • When you install v6.0.1, be sure to install v6.0.1 reports, launch it, and specify your access credentials, especially if you have scheduled reports. Your reports won't run until you do.
    • If you're interested in using TLS, use the CMC's "enabletls" command to toggle TLS support for reports (you'll have to export the cert using "exportcert" and then import into the reports console as well).


FIM (File Integrity Monitoring) Updates

  • Fix for the "NT AUTHORITY\SYSTEM" username when accessed by a fileshare: we put this out in a hot fix but now it's incorporated in the agent install and agent automatic upgrade. When someone accesses a file remotely, the username should be shown instead of the stock NT AUTHORITY\SYSTEM user.
  • Fixes for several configuration issues with FIM: we've had a few issues reported with FIM from customers - directories not displaying, for example - that we've resolved.


But Wait, There's More!

  • Support for SQL Auditor with SQL 2012: we're working on SQL 2014, too, but for now we officially support SQL 2012 with SQL Auditor, along with the previous support for earlier versions (2008, 2005, 2000).
  • Better support for large memory configurations: customers with high throughput have assigned extra RAM and CPU to the LEM appliance, but support often had to remote in and tweak some settings. We've improved our auto-tuning on startup to detect and support these configurations.
  • Several additional utilities and smaller fixes, including: improvements to our internal logging, a utility to rebuild indexes more easily, and as always more officially supported connectors (remember, you can download these at any time - see SolarWinds Knowledge Base :: How to apply a LEM connector update package)


Customers on maintenance can download the LEM v6.0.1 upgrade on the Customer Portal immediately. For everyone else, the download on the LEM Product Page is now v6.0.1, too.


Be sure to check out What We're Working on - Log & Event Manager Edition for some ideas on where we're going next. If you've got any questions about v6.0.1 or all things LEM, post them here or over in the Security Event Manager (SEM) - Formerly Log & Event Manager forum.

We've been getting an increasing number of questions about the ShellShock vulnerability that was announced, this post will collect the status across different products into one place to make it easy for you to determine if your product is affected or not.


What is ShellShock? How does it work?


ShellShock is a vulnerability in a command shell commonly used on Linux (and some other Unix flavors) - basically EVERY Linux system out there (before yesterday that hasn't been patched today) is vulnerable in some fashion. The vulnerability allows someone with local access to log in to a Linux system OR remotely run unchecked commands to a linux system (via the web, for example) to elevate their privileges such that they may even have root-level access (at least, they'll have the context of the process they exploited - the service or user account). At that point, changes could be made to the system, additional services could be run (to do things like serve exploit or phishing sites), and further exploits could be attempted to get root-level access and full control.


There is not YET a massive scale exploit of this vulnerability, but it's entirely possible that before the day is done, one will be in the wild (we're already seeing smaller scale exploits winding up). With so many web applications that control and access Linux systems (doing things as simple as image manipulation or as complex as system management control panels, for example) and the common usage of Linux for web servers and application platforms in general, it's probably not going to be very long before something is written and scaled to take advantage of this exploit and create a ton of zombie systems out there.


For more reading, there's a great summary post here: Troy Hunt: Everything you need to know about the Shellshock Bash bug


What SolarWinds Products are Affected?


First, anything that exists exclusively on Windows is not affected. This is the majority of SolarWinds products - including NPM, SAM, NCM, Patch Manager, and more.


Products installed on a Linux OS or used to manage a Linux OS are not vulnerable, but their underlying system may be. Storage Manager or Serv-U on Linux isn't affected, but if your Linux OS is, you should consider that system at-risk. Similarly, if you are using LEM agents or monitoring Linux systems, those software bits are okay, but the underlying OS probably isn't.


The only affected products are our virtual appliance-based products, which run limited versions of Linux.


Below is a chart of all products, which are affected, and mitigation or resolution steps you can take if necessary.

ProductAffected?Notes & Next Steps
Alert CentralPartially, See Notes

Alert Central is running a vulnerable version of bash, however at this point none of the exploit vectors apply:

  • Access to the virtual appliance shell requires authentication and the exploit does not elevate privileges.
  • It is not possible to exploit the vulnerability remotely.


To mitigate the threat, limit access to the virtual appliance management console and VAMI configuration interfaces where commands can be ran and instantiated. Ensure your appliance "admin" password used for VAMI access is set and secure.

To be safe, we will include the updated bash software in an upcoming Alert Central release. If it becomes necessary to issue a patch, we will do so. More info will be posted here.

Log & Event Manager (LEM)Partially, See Notes

LEM is running a vulnerable version of bash, however at this point none of the exploit vectors apply:

  • It is not possible to exploit the vulnerability interactively (customers do not have access to an authenticated bash prompt).
  • No LEM management commands allow setting environment variables or are used in a vulnerable way.

If you are still concerned, you should limit access to the virtual appliance management console and restrict SSH access to LEM using the LEM advanced configuration console (CMC).


To be safe, we will include the updated bash software in an upcoming LEM release. If it becomes necessary to issue a patch, we will do so. More info will be posted here.

Virtualization ManagerPartially, See Notes

Virtualization manager is running a vulnerable version of bash, however at this point none of the exploit vectors apply:

  • Access to the virtual appliance shell requires authentication and the exploit does not elevate privileges.
  • It is not possible to exploit the vulnerability remotely.


To mitigate the threat, limit access to the virtual appliance management console and VAMI configuration interfaces where commands can be ran and instantiated. Ensure your appliance "admin" password used for VAMI access is set and secure.

To be safe, we will include the updated bash software in an upcoming Virtualization Manager release. If it becomes necessary to issue a patch, we will do so. More info will be posted here.

Web Helpdesk (WHD)Partially, See Notes

Web Helpdesk is running a vulnerable version of bash, however at this point none of the exploit vectors apply:

  • Access to the virtual appliance shell requires authentication and the exploit does not elevate privileges.
  • It is not possible to exploit the vulnerability remotely.


To mitigate the threat, limit access to the virtual appliance management console and VAMI configuration interfaces where commands can be ran and instantiated. Ensure your appliance "admin" password used for VAMI access is set and secure. Please also note this KB article for WHD Virtual Appliance patch SolarWinds Knowledge Base :: Bash Code Injection Vulnerability - Shellshock.

To be safe, we will include the updated bash software in an upcoming WHD release. If it becomes necessary to issue a patch, we will do so. More info will be posted here.

Patch Manager No
Firewall Security Manager (FSM)No
Storage ManagerNoWhen the patch is installed on the same system, Storage Manager will continue to function normally.
Serv-U ProductsNoServ-U does not run any shell scripts except during install time and it sets no environment variables. The only other use of sub process spawning is direct shell commands to manipulate files, and no environment variables are set.
Network Configuration Manager (NCM)No
Kiwi ProductsNo
Enterprise Operations Console (EOC)No
Web Performance Monitor (WPM)No
Server & Application Monitor (SAM)No
Network Performance Monitor (NPM)No
User Device Tracker (UDT)No
Network Topology Mapper (NTM)No
Netflow Traffic Analyzer (NTA)No
Failover Engine (FoE)No
Mobile AdminNo
IP Address Manager (IPAM)No
VoIP and Network Quality Manager (VNQM)No
Free ToolsNo
Database Performance Analyzer (DPA)No
Engineers ToolsetNo


Can any SolarWinds products help determine if I have other systems affected?

If you've got Server & Application Monitor, user mcam posted a template you can use here in our Content Exchange: Bash Vulnerability Test. You can use this to check and change the status of a monitored Linux node if it comes up vulnerable.


How do I fix them or prevent them from being attacked?


The fix is pretty straightforward - check your Linux distribution maintainer for an update to bash, or as Troy Hunt suggested in his article, compile and deploy your own.


You can prioritize what to fix based on how the attack works (requires a shell to be ran to instantiate the attack):

  1. Systems with web or remote control applications that run local commands on the appliance after taking input from users
    1. If you can identify a known vulnerable application (e.g. cPanel), patch the application AND the system - there may be future attacks that the application will now also protect you from
  2. Systems with accounts where you allow people to log in and run commands arbitrarily
  3. Systems with sensitive data or access to sensitive networks
  4. Anything else!


If you can't fix something right away, here are some suggested mitigation steps:

  1. Disable or limit access to web or remote control applications that run local commands - ESPECIALLY from the public-facing internet.
    1. NOTE: If you're using SSH, it can't be exploited EXCEPT by an authenticated user, so you don't necessarily need to limit visibility entirely (though it may still be a good idea!)
  2. Disable or limit access (local or remote) from any unnecessary accounts.
    1. For accounts that run services, prevent them from logging in and spawning a shell.
      1. NOTE: Make sure any services you're running, especially accessible from the internet, use service accounts, not root.
    2. For accounts that only need access to something like FTP, prevent them from logging in and spawning a shell.
    3. Audit for dead accounts - users that may not exist any longer.
  1. Consider disabling login access to systems that have access to sensitive data or networks to only critical users while you deploy the fix.
  2. Monitor for common post-attack signs:
    1. Usage of the root account
    2. Services restarting (could be a sign of configuration changes)
    3. Accounts being created and/or sudo access being granted
    4. Monitoring systems being disabled/shut off


We'll update this post if anything changes or as more information becomes available on the updates for our virtual appliances.

Over the last 10 years, enterprise storage has been one of the most active areas of innovation and change in the IT environment. Storage forms the foundation of critical IT Server and Application infrastructure and IT Pros who are responsible for managing enterprise storage have had to learn and adapt as the demands of ever increasing business-critical applications push existing SAN and NAS architectures to their limits.  Most critically, virtualization of the server infrastructure has turned the end-to-end support of these applications into a rat's nest. This means that as end users clamor for better application performance and storage capacity, the Storage Pro is often left troubleshooting the environment with a collection of isolated tools to help him monitor, troubleshoot and maintain peak performance and availability. We've heard this loud and clear from the IT community and we believe there is a better way. With that I introduce you to SolarWinds Storage Resource Monitor (SRM), our new native Orion module to monitor and manage your storage environment. Best of all, we already have a Beta available and we are excited to get your direct feedback so we can make even more improvements before release. Since we are delivering this functionality as part of Storage Manager (STM) and Storage Profiler (PL) (more details below), the Beta is open to STM and PL customers currently on Active Maintenance. If you are not a Storage Manager customer, but are still interested in participating, go ahead and sign-up as well, and I'll see if there is a way I can at least get you on a feedback call to interact with a SolarWinds-local install.




Why SRM?


In 2010, SolarWinds acquired TekTools, which became our venerated Storage Manager product. Storage Manager is a very broad and deep product and has served to save the hides of many a Storage Admin from over-provisioned storage pools and LUN's behaving badly. However, we have heard consistently from you that when it comes to IT Operations Monitoring, you want a Single Pane of Glass view across the entire Application Stack (internally affectionately called "the AppStack"). Well, you'll be happy to know that we agree with that end-to-end vision of your IT environment - and we just can't pay that off by simply extending Storage Manager functionality on its current platform. SRM is the piece of the puzzle that along with our networking tools, Server and Application Monitor (SAM), Web Performance Monitor (WPM), and the recently integrated Virtualization Manager (VMAN) allows us to deliver to you a truly Application-centric view of your IT systems infrastructure performance and availability.


The AppStack



Given your direct feedback, it's become clear that the performance of an individual piece of the IT infrastructure - a LUN, an Array, a VM, an ESXi Host - is only as important as it serves the overall health and availability of the business critical application it supports. To that end, SRM is built to finally give you a NOC view of your storage environment side-by-side with it's related physical and virtual servers and the applications running on them. Furthermore, the Orion platform was built from the ground-up to be a NOC platform and trying to make the current STM platform fit that model would be a extremely difficult feat at best. What do I mean by a NOC platform? Very simply all of the goodness you've come to expect from the Orion platform: Status, customizable UI dashboards, custom properties, a rotating NOC view, extremely flexible alerting and reporting, customizable UI widgets (e.g. custom Top 10's), the Network Atlas.....the list goes on. By bringing your storage data onto the Orion platform, we can enable you to see and interact with your data in the way you want and we're very excited to make this happen for you and your organizations.


Your New Storage Home

9-18-2014 9-51-47 PM.png


Wait, but I own Storage Manager! What happens to me?


You'll be happy to know that you're coming along with us on this ride. Hopefully, you're as excited as we are. SRM will be delivered very similarly to how we've delivered the Virtualization Manager integration with NPM and SAM. Storage Manager and Storage Profiler customers on Active Maintenance at the time of GA will be entitled to SRM as part of their Maintenance.


Does this mean that I need to own another Orion module product (e.g. NPM, SAM) in order to deploy SRM?


Absolutely not. SRM can be stood up on it's own, the same as any stand-alone Orion module. However, the team is working extremely hard to ensure that there is seamless integration across our primary "Systems Management" products so you can get full end-to-end visibility when you deploy SRM with SAM or VMAN. As I stated above, the end goal is to give you full Application to Array visibility of your IT environment whether your applications are running on physical or virtual servers and integration with SAM and VMAN are key to fulfilling that vision. Continue watching the Product Forums and Product Blog for updates about upcoming SAM Betas and VMAN Betas to test this out in your own environment.


Furthermore, you can continue to run Storage Manager in your environment and we're working hard on making sure our licensing allows you the flexibility to deploy the way you need to in order to meet your business requirements.


Do I need to be running STM in order to run SRM?


No. Unlike the current VMAN integration where the VMAN Virtual Appliance is feeding data collected from your VMware and Hyper-V environment to the Orion database, SRM has been developed to collect data directly from your arrays (or their data providers like SMI-S). SRM is a native Orion module and does not collect or share data with Storage Manager beyond that required to enforce licensing.


OK, but will you support MY device?


The Enterprise Storage market could be an academic case study in long-tail markets. Furthermore, each of the vendors have made data collection and device modeling completely different across every array family - even array families ostensibly under the same brand name or corporate umbrella. Long story short, we have to make choices on where to start and matching all of STM's incredibly deep array support in v1 simply wasn't feasible. So where did we start? Our current Beta has support for:


  • The EMC VNX Family - This includes EMC's VNX (formerly CLARiiON) and VNX2 architectures as well as the VNX NAS Gateway devices (formerly Celerra). VNX enthusiasts I have good news - We will now have full block and file (Unified) support under a single device type.
  • The Dell EqualLogic PS Series (SAN)


In short order, we should have a Beta available for:



I promise you that's not where our vision ends. Stay tuned for more info. Either way, I encourage everyone interested to sign-up for the Beta - the survey will ask what devices you have in your environment and I'll be proactive in reaching out to folks when your device is ready for Beta testing.


So What's Next?


You can be assured that this will not be the last post on this topic before the product is released. I'm sure you have outstanding questions I have not addressed, so please don't hesitate to ask and I'll address them directly and/or roll them up into follow-on posts! Furthermore - go sign-up for the Beta and try SRM today!

You can find the installation packages in your customer portal. This service release:


  • Upgrades Orion Platform (2014.2.1):
    This version includes the latest Orion Platform features and versions of existing components.
  • Includes a Parameter for Specifying a Password Prompt in Device Templates:
    This version enables you to specify the password prompt issued by a device as part of the device template, in case NCM is having trouble recognizing the device's prompt (for example, due to unsupported characters).
  • Enhances Support for SWIS Connections:
    The version modifies NCM software to process SWIS connections to any poller.
  • Accounts for the SolarWinds Alerting Service V2:
    This version fixes a problem with the NCM installer not shutting down a specific Orion Platform service.
  • Restores Test Button:
    This version fixes an error with Test button in Edit Properties resource for a node.
  • Enforces Reserved Words:
    In this version NCM ignores custom property names that include reserved words.
  • Moves a Data Migration Module:
    This version fixes a bug related to the location of data migration code module.
  • Restores "Overall Policy Violations" Resource:
    This release resolves a problem that prevents this resource from displaying.
  • Supports SQL Server 2012 SP2:
    NCM now supports this version of SQL Server.


Further details and list of fixed issues can be found in the release notes.

We are currently in the planning phase for the next release, we are investigating following areas. As we move forward we will update this post to reflect what we are working on short-term.

Some of these items include:


  • Support for new VMware versions
  • Support for usage of TLS 1.2 only (after 1.1 disabling)
  • Bug fixes


PLEASE NOTE:  We are working on these items based on this priority order, but this is NOT a commitment that all of these enhancements will make the next release.  We are working on a number of other smaller features in parallel.   If you have comments or questions on any of these items (e.g. how would it work?) or would like to be included in a preview demo, please let us know!

Dear Network Admin,

It's a pleasure for the whole User Device Tracker product team to announce that UDT 3.1 is now Generally available at the customer portal!


This latest UDT release brings some significant improvements to the existing Discovery as well as new features so let's recap what is included:


As you can see, we absorbed a lot of your feedback and we plan to continue... Therefore, please feel encouraged to submit even more feature requests so we can make the product even better!

A special thanks goes to Beta and RC takers who sacrificed a bit of their time to help us make the product more stable...


Best Regards

Peter Ksenzsigh

In order to make the process of upgrading to NPM v11 as easy and seamless as possible, we have pulled together a number of resources to assist you.

The Benefits of Upgrading to NPM 11

  • Benefits of Upgrading to NPM 11:  In this 2-minute video, Rob Hock, SolarWinds group product manager, guides you through the newest features of NPM, deep packet inspection and analysis.




How to Deploy Packet Analysis Sensors


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



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


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


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


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


Agent Deployment - Add Node Wizard


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

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

Agent Deployment Wizard


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


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

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

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

Mass Agent Deployment Option

Mass Agent Deployment Option.png

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

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

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

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

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

Manual Agent Deployment Option



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


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

Agent Management

Global Agent Settings.png


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


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


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

Delete Agent Node.png

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

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

Over the course of the last few weeks we have held a number of webinars with customers about NPM version 11 and the new deep packet inspection and analysis capabilities.  Throughout those webinars, a number of common questions have come up.  Below you will find a list of FAQs that we hope will address most of those questions.


Q - We have an existing NPM license, can we freely upgrade to the latest version?

A - Yes, if you are an NPM customer under active maintenance then you can upgrade to version 11 free of charge and take advantage of the out-of-the-box packet analysis sensors.


Q - Is the upgrade from NPM 10.7 to NPM 11 seamless?

A - Yes, the upgrade process is a seamless process.


Q - Is Quality Of Experience and deep packet inspection and analysis included (free) with NPM v11?  Or does QoE require its own licenses?

A - The QoE dashboard and deep packet inspection and analysis are included out-of-the-box with NPM along with one network packet analysis sensor (NPAS) and ten server packet analysis sensors (SPAS).  Additional sensors can be purchased.


Q - If we already have an unlimited NPM license, am I still limited to 1 network sensor?

A - Yes, the one network and ten server sensors included out of the box apply to licenses of all sizes.  You can, however, purchase additional sensors to scale your deployment.


Q - What are the system requirements for NPM 11 and  the packet analysis sensors?

A - For your Network Performance Monitor server, the system requirements have not changed.  You can find them here  or in the Administrator Guide

For Packet Analysis Sensors the requirements are as follows:

Windows 7 / Server 2008 64-bit or later (32 bit operating systems are not supported)

2 CPU cores + 1 CPU core per 100 Mbps


1 GB (2 GB recommended) RAM

1 Gbps maximum throughput

Network Packet Analysis Sensors (NPAS) require a SPAN, mirror port, or in-line tap on the monitored switch


Q - What is a packet analysis sensor?

A - Packet analysis sensors are agents that capture and analyze network traffic packets.  They can be installed directly on an application server to capture and analyze the traffic from the application(s) on that server or they can be installed on a dedicated server connected to a switch SPAN port to capture and analyze the traffic on the SPAN port.


Q - Can sensors be used without installing any agents?

A - No, sensors are agents that reside on an application server or a dedicated server monitoring a SPAN port


Q - Can sensors be deployed to both 32 and 64 bit servers?

A - No, only 64 bit servers are supported.


Q - Would a mulit-homed server work as a sensor?

A - Yes


Q - What is the difference between a network sensor (NPAS) and a server sensor (SPAS)?

A - Network sensors (NPAS) reside on a dedicated server that is connected to a switch SPAN port and will capture and analyze application traffic that passes through the SPAN.

Server Sensors are deployed directly on a server that hosts an application that you would like to monitor traffic to and from and will monitor only the application traffic on that specific server.

Q - Are sensors limited to physical servers or can you use a virtual machine as a sensor?

A - Sensors can be deployed on a physical or virtual server.

Q - Does the sensor have to be on a computer with a 1GB NIC?

A - No, you do not have to have a 1GB NIC on your server, however, you will be limited to monitoring traffic at the throughput of your NIC.

Q - When doing a network sensor, can you use multiple interfaces?

A - Multiple interfaces may be spanned or mirrored to a network packet analysis sensor.

Q - Do the server sensors have to be on a dedicated server or can it be running other applications?

A - The server sensors are deployed directly on the server hosting the application.

Q - Does the sensor have to be on the same LAN as the SolarWinds server?

A - No

Q - Can sensors be run on the same Orion NPM server but with a dedicated NIC for the SPAN / mirrored port?

A - Yes

Q - Do we need to SPAN ports if all nodes and network sensor are in the same VLAN but in different switches?

A - You would need to SPAN ports on each switch.

Q - Is there a Linux agent/sensor?

A - Not at this time but we are looking at that for future releases

Q - Can I monitor Linux servers?

A - At this time there is not a Linux sensor.  It is something that is planned for future releases.  You can, however, monitor the application traffic from a Linux server through the connected switch using a network packet analysis sensor

Q - How many servers can be monitored by one network sensor?

A - There is no theoretical limit to the number of servers that can be monitored by one network sensor.  However, a single sensor is limited to monitoring 50 applications and a maximum of 1Gbps of throughput.

Q - Do you do application discovery?

A - Not at this time but we are looking at that for future releases

Q - How many application signatures are supported?

A - Over 1200

Q - Are these signatures updated dynamically through product updates?

A - Yes

Q - Can custom applications be defined?

A - Yes, custom HTTP applications can be defined.

Q - Are there any options for creating custom non-http application definitions?

A - Not at this time but we are looking at that for future releas

Q - Can QoE monitor SolarWinds Orion as one of the applications with variable response times?

A - Yes, using an HTTP application and/or a SQL applicaiton

Q - How does QoE impact the SQL database load?

A - There is a trivial impact on the SQL database load.

Q - What is the overhead at the Orion server level and at the monitored node?

A - There is minimal overhead on the Orion servers and typically a 10% overhead on the monitored node.

Q - How much detail is captured and what is the realistic amount of time it can be retained?

A - The only detail captured and retained is Application Response time, Network Response time, traffic volume and traffic count.  Retention time is configurable.

Q - How much additional bandwidth is required to send data back to the Orion server?

A - Minimal, since data is aggregated in 5 min intervals

Q - What ports are used by the server sensors to talk back to Orion?

A - TCP 17777 and 17778

Q - How best can I determine my sustained load?

A - Using the current interface statistics

Q - Do I need to use a separate database?

A - No

Q - Does the capture data stay on the Sensor host?  And what is the impact to storage/resource on the NPM host?

A - No payload data is stored

Q - How is DPI different from SAM?

A - Server and Application Monitor (SAM) provides up/down and performance monitoring for servers, and 150+ applications.  SAM does not monitor the response time or latency of an application so it has no concept of perceived end user experience or application quality of experience.  DPI and QoE, on the other hand, will provide the network and applicaiton response time that a user would experience.

Q - Is Server & Application Monitor (SAM) required?

A - No, SAM is not required, however, it does provide valuable additional insight into application status and performance.

Q - We have NPM, but not SAM, what would be the limit of the displays?

A - You would be able to determine that it's an application issue, but the drill-down would be limited to the high-level server metrics (CPU, memory, disk).  To get app performance and detailed server metrics (including HW health), you'd need to have SAM.

Q - Is AppInsight for SQL included with NPM 11 or do I need to purchase it seperately?

A - AppInsight for SQL is part of Server and Application Monitor (SAM).  It is purchased separately.

Q - How is QoE different from NTA?

A - NetFlow Traffic Analyzer (NTA) tells you how network bandwidth is being consumed but looking at the who, what, where, and how of bandiwdth utilization.  NTA has no concept of latency or user experience.  DPI and QoE, on the other hand will tell you how the end user is experiencing the application but not what the impact on network bandwidth is.

Q - Does NetFlow need to be enabled?

A - No, NetFlow is not required for DPI and QoE.

Q - Are you going to build the capability to ingest Cisco ART metrics from IPFIX?

A - It is under consideration.

Q - Are there any QoE report templates?

A - We have Top XX resources that can be used on reports

Q - Do you support Cisco RSPAN?

A - Not at this time.

Q - Can traffic be parsed between client machines and citrix vm/applications?

A - ICA traffic is supported.

Q - Can you monitor response time between remote client and specific server as opposed to from the NPM server to the app server?

A - Yes, that is default behavior.

Q - Can NPM measure application level jitter, errors, and packet loss?

A - Not with QoE at this time.  It can, however, be accomplished using VoIP and Network Quality Manager based on IP SLA technology.

Q - Do you have a sensor to detect rogue WiFi?

A - Not at this time.

Q - Does this support NetBios traffic?

A - Yes

Q - How is data deduplication handled? 

A - Data duplication is not possible presently, therefore no need to dedupe.

Q - How well does the network sensor work over a WAN link limited to 20Mbps or less?

A - There are no known issues.

Q - How does it deal with seeing the same packet at multiple points (e.g. if you are sniffing at a site as well as in a data center and seeing traffic passing through both points)?

A - Data duplication is not possible presently.

Q - How best would I deploy in a multi-switch environment?

A - See deployment guide

Q - I see signatures for YouTube and Skype.  Is QoE able to monitor these types of social traffic for a network link or only for a network node?

A - On a per node basis.

Q - Can Citrix traffic be decoded?

A - No, but we measure ICA response time.

Q - If using a VM stack, can QoE and NPM and NCM reside on the same host?

A - Yes

Q - If our NPM server resides in the same data center as the application server, will the results not be relative to local infrastructure and not remote users experience over the WAN?

A - No, relative to transaction between Client and Server


Q - In an environment where you have a number of VRFs where the same IP addresses can exist on the same device, can SolarWinds understand devices to both the VPN/VRF and device?

A - Devices need to be managed nodes, so as long as this requirement is fulfilled, there should be no issue


Q - How do additional polling engines impact deployment?

A - Sensors will send data to the assigned APE.


Q - Can the data collection and storage be configured?

A - QoE uses standard retention settings


Q - Is there a brand of TAP device that you would suggest?

A - We are aware of customers using Gigamon


Q - Would you want to place a TAP on each switch or on a core router

A - See deployment guide


Q - Is there an equivalent to a PCAP file that is being stored somewhere on the server?

A - No - all in memory


Q - Does NPM support the Nexus series from Cisco?

A - Yes


Q - Once all sensors are installed and reporting, is there a fair amount of configuration within the console for all of the information you have just shown to populate? Or does that information populate automatically?

A - Application response time, network response time, data volume and transaction count are all automatically calculated and displayed in the console with no configuration required.


Q - We use 10 Gig links in our Data Center and throughout our main office.  What can I do to use this product to monitor this 10 Gig network?

A - Using a hardware tap would be advised (EX: Gigamon)


Q - Is Nexus 1000v supported?

A - Yes


Q - Can NPM receive input from a Wireshark capture?

A - No, NPM does not take input from Wireshark.

I'm very pleased to announce General Availability of Web Performance Monitor 2.1. This release is full of great new features and improvements. Namely,

  • Tighter integration with Server & Application Monitor (SAM) and Network Performance Monitor (NPM) to help you identify problems in your Web Application infrastructure faster
  • Ability to create dependencies between Transactions and other Orion objects like Groups or Interfaces and also between Locations and other Orion objects
  • Recorder usability improvements include:
    • Positive and negative text and image match
    • Simple conditionals to handle web application variance
    • Ability to multi-select steps for easier editing in Recorder
    • Multi-variant text inputs
    • Logically group transactions and recordings with custom properties
  • Support for web-based reporting
  • and many other


You can find more details in Web Performance Monitor 2.1.0 Beta is available blog post and Web Performance Monitor 2.1.0 - What's Coming in Recorder. Detailed description of this release is also available in Release Notes.


WPM 2.1 is available in your customer portal today or you can download evaluation version from WPM product page.


Please let us know if there are any questions. Comments welcomed below.

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.