1 2 3 4 5 Previous Next

Product Blog

572 posts

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



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


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



HTML tutorial



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


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


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


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

List Resources.png


Network Sonar One Time Discovery.png

Network Sonar Discovery Results.png



AppInsight for IIS Configure Server.png

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


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


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

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


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


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




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


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


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


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


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



Response Time.png


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


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


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


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


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


AppInsight for IIS - Management.png



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

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

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

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


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

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


NCM v7.3.2 is Now Available

Posted by cvachovecj Sep 16, 2014

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.


What We're Working on for NTM

Posted by cobrien Sep 10, 2014

NTM 2.2 is out the door and we're hard at work on the next release.  Here's some of the stuff we're working on:



The list is short because we're currently thinking about what we'd like to focus on in the next release.  Have an idea?  We'd love to hear about it!  Add it here: Network Topology Mapper Feature Requests


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.

To receive updates on the Virtualization Manager  roadmap, JOIN thwack and BOOKMARK this page.

We are currently working on Virtualization Manager 6.2 and beyond.  Some of the items we hope to deliver:



  • Stand-alone Virtualization module on Orion Platform. Once installed, you have a "Home" and "Virtualization" tab no NPM or SAM required, though they continue to ship with the virtualization support they have today.
  • Application stack integration and visualization (e.g. visual mapping through the entire application stack to help identify root cause of performance and availability issues)
  • Management resources to allow users to take simple actions in their virtual environment (e.g. Start/Stop/Reboot a VM, Take recommended resource correction (increase/decrease and reboot) as recommended by VM Sprawl, Take/Delete a snapshot)
  • Better handling of Hot Fix installs for VMAN Appliance
  • Add Costop % Counter (VMware)
  • Out-of-the-box (OOTB) reports for VMAN on Orion
  • Port remaining VMAN alerts to Orion
  • Capture per VM HBA and per VM NIC data
  • Add SAM Template for VMAN to SAM for monitoring VMAN (aka "who watches the watchmen")
  • Support for VMware Tags
  • Licensing usage and upgrade messaging improvements
  • Support for vCenter Server Appliance (vCSA)


Disclaimer:  Comments given in this forum should not be interpreted as a commitment that SolarWinds will deliver any specific feature in any particular time frame. All discussions of future plans or product roadmaps are base on the product teams intentions, but those plans can change at any time.


If you don't see what you are looking for here, you can always add your idea(s) and vote on features in our Virtualization Manager Feature Requests forum.

As the excitement builds for NPM 11 release, you should begin to consider the best options for sending data to your Network Packet Analysis Sensor (NPAS).  Highlighted in NPM 11 - Packet Analysis Sensor Deployment Considerations, we briefly discussed how to capture and export data over to the NPAS. Figure 1 shows the network packet analysis sensor installed on a dedicated server with dual NICs.  A primary NIC for management access and a secondary NIC to passively listen for all traffic.  When it comes to data collection, the secondary NIC is capable of accepting:


  • TCP packets from a SPAN(Mirror Port)
  • TCP packets from a network tap
  • TCP packets from Network Packet Broker


Figure 1


Things to consider for deployment options:

  • Where are my critical applications hosted?
  • What are the major aggregation points of my network?
  • What are the line rates at critical capture points?
  • Avoiding packet duplication


Connecting a NPAS directly to TAP and SPAN ports in a network is the simplest way to get data for analysis, but this approach has several pitfalls. The most immediate problem is that there are just not enough TAP and SPAN ports for all of the tools used by the typical IT or engineering team.  Modern network architectures provide multiple paths through the network, which helps increase network availability, but it also puts challenges on complete network visibility.  This redundant network design provides continuous access to data in the event that one or several links should fail.  However, the redundancy also means that data between two devices in the network may not travel in the exact same path through which may be missed if the network packet analysis sensor is not deployed properly.


In addition to determining the best location to place the NPAS, you will need to take measures not to oversubscribe  the output capacity of the mirror port.  In high-traffic situations, you can limit the amount of traffic on the SPAN or mirror port. For example, set an Access Control List (ACL) on the mirror port to forward only traffic from key servers. By leveraging an ACL, you can eliminate unnecessary traffic before it is sent out of the mirror port.  If you use an ACL, verify that all TCP traffic is forwarded to the monitor. Then add other protocols used by the critical applications you want to monitor. Specify the appropriate ports in the port mirroring statement.  You should avoid scenarios where a large capacity switch transmits data from all ports to one mirror port or SPAN.


Aside from your traditional techniques to mitigate the previous risks, the introduction of network packet brokers have made taken this capabilities to whole new level. Gigamon is one of a handful of vendors that offer products that provide enhancements in how data is sent to monitoring tools. Gigamon products  deliver Intelligent Traffic Visibility Networking Solutions to enhance network monitoring of data centers, service providers, and enterprises.  Figure 2 shows two network packet analysis sensors taking feeds directly from the GigaVUE - 420 appliance. 


Some of the feature and benefits include: 

  • Any-to-Any connectivity
  • Aggregate 10G links to 1G tools
  • Intelligently filter via Citrus™ web GUI or CLI
  • Replicate traffic to multiple monitoring tools
  • Solutions for monitoring asynchronously routed traffic



The GigaVUE-420 Traffic Visibility Node supports 10/100/1000 & 10Gig Ethernet. GigaVUE-420 aggregates, filters, and replicates traffic flows across multiple security and monitoring tools. Hardware filters based on any pattern in the 128-byte header may be enabled to eliminate unwanted packets. The GigVUE-420 modular design allows network professionals to deploy the exact number of ports necessary to fit their requirements.


The GigaVUE-420 enables the Traffic Visibility Network to unobtrusively monitor the production network. The GigaVUE-420 provides out-of-band ports for passive monitoring tools. Tools may be added without affecting the network, at any hour without configuration management review. Multiple GigaVUE-420 systems can be stacked to create a 222 port visibility fabric. All ports can be configured as network or tool ports.


So whether you are using legacy techniques for capturing data or have access to more advances NPBs, Solarwinds’ NPAS is a great way to determine whether it is the application or the network.  Now go sniff some packets!!

Yesterday we announced a big change about how we license and price SolarWinds Database Performance Analyzer (DPA).


DPA is a tool that has helped thousands of organizations improve application performance and fix problems for which it was very hard to find a root cause. Since I joined SolarWinds five months ago, I have heard many times from customers, “This is the best tool I have used.” With the licensing changes, we want to expand the number of teams that can take advantage of DPA.


First, we are aligning DPA licensing with how IT organizations are evolving. Traditionally, enterprise software has been licensed per core. Virtualization, cloud and modern microprocessor technologies have made the concept of core ambiguous or irrelevant. So we’ve transitioned DPA to a 100% instance-based licensing model for all our supported databases: SQL Server, Oracle, Sybase and IBM DB2. With instance-based licensing, we’ve eliminated the complexity of figuring out how many cores are supporting a database.


We are making our award-winning performance analysis tool both more affordable for a larger group of customers with smaller database installments as well as larger IT organizations with thousands of databases. Quite simply, we lowered the price.


We’ve seen our larger customers wanting to reach 100% monitoring coverage across all their environments. Instead, many have to pick and choose to monitor their most critical production instances because of cost restraints. The new pricing model enables large IT organizations to deploy DPA across both physical and virtual machines as well as production, test and development environments.


DPA for SQL Server and Oracle Standard Edition now starts at $1995 per instance (and goes down based on volume). DPA for Oracle Enterprise Edition, Sybase and DB2 starts at $3495 per instance. These prices include the first year of maintenance.


With this new licensing and pricing model, SolarWinds is delivering on its promise to make IT management simple and affordable for our customers.


Learn more about SolarWinds Database Performance Analyzer.


As promised in my earlier blog post entitled, "SAM 6.2 Beta - Because sometimes you feel like a nut - Part 1," here are some additional scenarios where the new agent included in the forthcoming Server & Application Monitor 6.2 beta could prove beneficial in ways you may not have even thought of yet. (As a reminder, SolarWinds remains firmly committed to our "Agentless First" approach for virtually everything we do!)


For those who need an agentless alternative to monitoring certain aspects of their environment, the new and optional agent is yet another powerful tool in your arsenal. Where you might wield this new weapon is entirely up to you.


Below are three additional examples in a continuing series where I outline some of the tangible benefits of the agent. If you'd like to kick the tires on the new agent, please feel free to participate in the SAM 6.2 beta. We'd love to get your feedback. Simply sign-up by clicking the link below:



SAM6.2Beta Button.png

Head in the Clouds


Monitoring applications and servers running in the cloud using traditional agentless protocols is fraught with issues. For instance, by default, the WMI protocol is not fully encrypted, nor will it traverse NAT boundaries. WMI also requires a healthy number of open ports to function properly, not to mention that it's a fairly chatty protocol that doesn't tolerate bandwidth congestion or high latency conditions very well. Problems like these are further exacerbated by the fact that many ISPs block RPC traffic on the internet due to the protocols historical association with worms and hacker exploitation.


Unfortunately, the SNMP protocol fares only slightly better than WMI. Currently, all versions of Windows still rely upon SNMPv2, which provides no authentication or encryption. While SNMP has been designed to work in harsh bandwidth contentious environments, as well as traverse firewalls with ease, there still remains an ever decreasing amount of useful information available that can be collected from Windows devices via SNMP. This fact alone, coupled with Microsoft's recent depreciation of SNMP in Windows 2012, suggests that no further dependency should be built on the protocol for monitoring Windows devices.


Passive vs Active.png

The agent included in the SAM 6.2 beta allows you to monitor servers hosted by cloud based services such as Amazon EC2, Rackspace, Microsoft Azure, or virtually any other Infrastructure as a Service (IaaS).

Agents installed on Windows servers hosted in the cloud are then monitored by Orion no differently than any other server in your environment. Each agent can be configured independently to operate in the mode that best suits your needs. For instance, you may want to use Server Initiated mode for servers hosted on Amazon EC2 because they all have publicly routable IP addresses. Conversely, you may want to use Agent Initiated mode for servers you're hosting in Azure because these servers may be hidden behind a NAT.


Each agent can also be configured to communicate with a specific Orion server or additional poller for load distribution.

Once deployed, the agent eliminates the issues associated with the WMI and SNMP protocols outlined earlier. All communication between the Orion server and the agent occur over a single fixed port. This communication is fully encrypted using 2048 bit TLS encryption. The agent protocol not only supports NAT traversal, but also supports passing through proxy servers that require authentication. The protocol the agent uses has been designed from the ground up to be extremely efficient and operate in low bandwidth, high latency environments. This makes it ideal for monitoring servers located in the cloud.


Finally, the agent is far more secure than either WMI or SNMP simply because there are no listening ports at the endpoint when using the Agent Initiated mode. This means there is zero attack footprint exposed by the Agent on the monitored endpoint that could be leveraged and exploited remotely by hackers or cyber criminals. Both SNMP and WMI expose listening ports on the host where they are running, making the agent a much more attractive option for monitoring servers running in the cloud.


You can't keep a good agent down


Agent Connecivity Failure.png

Unlike traditional agentless monitoring techniques, the Agent included in the SAM 6.2 beta is resilient to failure. In the unlikely event the Orion Server or Additional Poller were to go down for any reason, agentless monitoring of any hosts or applications monitored by that poller stops until that server is brought back online. This leaves gaps in performance charts and availability reports. This is also true for other types of failures that can occur anywhere in between the poller and what's being monitored, such as network equipment issues, WAN circuit problems, or VPN tunnel hiccups.


The agent, on the other hand, operates independent of the poller it's associated with and continues monitoring the server and its applications, regardless of whether or not it can communicate with the poller. Once connectivity to the poller is restored, the agent then forwards the results of its monitoring during the outage to the poller for processing, All gaps in the data will be filled with the data collected by the agent that would have ordinarily been lost if the host were being monitored without an agent.

These were just a few additional scenarios where you might find using an agent beneficial in your environment. As previously stated, the new agent is completely optional and intended to address specific needs where agentless monitoring of Windows hosts is either difficult, or simply not possible. As my final example demonstrated, there are other advantages the agent can provide to complement your agentless monitoring architecture. I will outline more examples in a follow-up posting, as well as provide a walkthrough of some of the agent deployment methods that are available in the beta.


The SAM 6.2 beta is not yet available, but will be very soon. If you would like to sign-up to participate in the beta, you can do so by completing a short survey. You need only be an existing SAM customer under active maintenance. Once available, you will be notified via email with a download link to the SAM 6.2 beta.

Filter Blog

By date:
By tag: