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

With the release of Orion NPM 11.0 and the SAM 6.2 Beta, we are introduced to a new extension to the Orion Family: the SolarWinds Orion Agent.  We cover the below procedure step-by-step in the Orion NPM Administrator's Guide, but we skip all of the "why's and what's" about the process.  I'm hoping that this post will demystify some of the steps involved with setting this up within Patch Manager.


I chose to call out the Orion Agent to showcase custom package creation within Patch Manager because it's an almost perfect application for a couple of reasons:

  1. It is packaged as an MSI file
  2. It has simple rules about its compatibility
  3. It has some customization that needs to be passed to the installer

All in all, it gives me the ammunition to show how to use Patch Manager to install a custom application with some (but not too much) complexity.  Although this step-by-step calls out the Orion Agent for package creation, there is no reason that you cannot use this procedure with any custom package.  In fact, after you go through this process with the Orion Agent, I highly encourage you to try it with a package of your own choosing.  But, without further ado, let's dig in!



Isn't Patch Manager just for Patches?

If you really think about it, patches are nothing but small software programs which just happen to "fix" other preexisting software problems.  The beauty and elegance of the Patch Manager solution is that you don't need to learn sixty different command line parameters, all of the switches for the Microsoft installer, or pretty much anything when deploying Third Party Software patches.  With Patch Manager, patching third party applications is as easy as 1 (download the package), 2 (publish the package), and 3 (approve for deployment).


So, you ask yourself, "Self, if patches are really just little programs with some rules, what's preventing me from using Patch Manager to deploy my own programs?"  The short answer:  Nothing!


Some background on the Windows Update Agent's Checks

If you dig into any of the predefined packages within the SolarWinds Patch Manager 3rd Party Update Catalog (3PUP), you'll see that there is all kinds of goodness that we pack into the tabs along the bottom.  If you don't have Patch Manager, download a copy and you can follow along.  Open up the Patch Manager Console, and check out the some entries in the catalog.  Go ahead, I'll wait.... **humming Tetris® theme to self**


So now that we're all looking at the same screens, I can continue.  There are a total of six tabs for every package; Package Details, Prerequisite Rules, Applicability Rules, Installed Rules, Content, and Version History.  I'm only showing the first four above and I'm only going to deep dive on the tabs for Prerequisite Rules, Applicability Rules, and Installed Rules.  I think of these rule tabs as answering very simple questions about the package:

  1. Prerequisite Rules
    Does this program apply to the target computer as a whole?
  2. Applicability Rules
    Does this program apply to the installed software on the target computer?
  3. Installed Rules
    How do I know if this is already installed on the target computer?

If you really want a super deep dive on these rule sets, you can dig in to Update Applicability Rules on the Microsoft MSDN Pages.  If you plan on digging into further custom packages (which you should), then I highly encourage you to read this article on the deep logic used in these rules and how it applies to Patch Manager.  Otherwise, just consider this post as a quick primer  - we'll give you enough information to get started.


Let's Build Us a Package!


Step 1 - Get the Installer Files

Since I've chosen the Orion Agent as our software package for custom package deployment, we'll need to get the necessary files for installing it.  The Orion Agent consists of two files, an MSI (the installer) and an MST (a transform file).  In very simple terms, a transform file is a "recording" of the information that you enter while running an installer.  Think of it as a script for all the text boxes, radio buttons, and check boxes for which the installer prompts.


You get these two files from within the Orion Web Console.  Launch the Orion Web Console with Admin rights, and go to Settings, then Agent Settings, then Download Agent Settings.  From there download the two files (MSI and MST) from the Mass Deployment Pane.  In my environment, I downloaded the MSI and MST file and saved them with the names SolarWinds_Agent_1.0.0.866.msi and SolarWinds_Agent_1.0.0.866.mst.  You can name them whatever you want - the above naming scheme just helps me keep the versions straight and I find that replacement of any spaces with underscores generally tends to be helpful.  I also saved them in a staging folder (C:\Staging\Tools\OrionAgent).  Again, this was just to help me keep everything straight.


Now it's time to start the package creation.  Navigate down in the Patch Manager Console to "SolarWinds, Inc. Packages" (you should find it under Patch Manager / Administration and Reporting / Software Publishing / SolarWinds, Inc. Packages) and click on it.  Now click on "New Package" in the Action Pane on the far right side of your screen.  Please note that you don't really have to navigate down to the "SolarWinds Inc. Packages" entry in the tree, you can create a package from any node under the Software Publishing node.  Again, this is just my preferred way so that I can keep things straight in my head..


Step 2 - Package Creation

Package Information Screen

Now you are in the Package Wizard. (Click on the image to pop up a larger version of each)


Above are the minimum entries that you'll have to make for a package.  Please be sure to change this for the proper version of the program.  Please take note that the Product entry (where it says Orion Agent) needs to be hand-typed the first time that you run through the wizard.  Once the information looks good, click Next to move onto the next screen.

What did we just do?

We just created the base information which categorizes the software package and how it is deployed.  The two important fields here are the Impact and the Reboot Behavior.  The Impact is used to determine the push schedule.  If you have Allow Automatic Updates immediate installation setting within your Windows Update Policy set to True, and the Impact is set to Minor, the install can take place immediately at next check-in by the Windows Update Agent.  If it is set to Normal, it is handled as all other patch tasks.

Reboot Behavior determines if the product requires a reboot.  Many products will, but some may not.  This is normally determined by the software package itself.  The Orion Agent does not require a reboot, so we've selected Never Reboots.

Prerequisite Rule Screen

Here is where having some background on the Rules is super helpful.  From reading about the Orion Agent, we already know that it supports Windows Server operating systems with Windows 2008 R2 and later.  It's also not recommended to be run on Domain Controllers.  So with that in mind, let's build that rule.


On the Prerequisite Rule Screen, click Add Rule.  Select Create Basic Rule as the format, and then Windows Version as the Rule Type.

  1. For Comparison, select Greater than or Equal to
  2. Enter 6 for the Major Version
  3. Enter 1 for the Minor Version
  4. Leave SP Major Version and SP Minor Version as 0
  5. Leave the Build Number empty
  6. Select Server for the Product Type

Click OK to save the rule and Next when you see the rule in the list.


What did we just do?

In simple words, we just created a prerequisite rule that says "check the Windows Version of the target computer and verify that it is a Windows Server version 2008 R2 or later running on a Server."  Windows version information (5.2, 6.0, 6.1, etc.) is explained a little more here.  Additionally, if you feel that this rule could be used repeatedly, you could have checked the box and save the rule with a name (Like "Windows 2008 R2 Servers or Later").


Select Package Screen

Here's where we tell the software how to install.  With MSI files, it's pretty straight forward, but I'll run you through the process step-by-step.

  1. Select Windows Installer as the Package Type.
  2. Move the radio button under Details down to I already have the package, click the browse button on the right and browse to your MSI file.
  3. You will get a popup indicating that the package has been downloaded and then one which asks if you trust the package.  Click OK to dismiss each of the pop-ups.
  4. Now take a step back.  You'll see something new on this screen.  The Product ID has been populated near the top (just under the Package Type).  Select this and copy it to the clipboard.  You'll need it in the next step.
  5. Further down in Details, check the box next to Include additional files with the package and click the package content button on the right side.  On the select additional files screen, click Add File and browse to your MST File.  Then click OK to close the Package Content Editor.  Click on Yes to copy these files.
  6. Back on the Select Package Screen, select the Binary Language as None.
  7. Finally, enter TRANSFORMS=<Full Name of MST File> in the Command Line (silent install) field.  This is the part where replacing spaces in the MST file with underscores (or something else) is handy.  If you have spaces, you'll need to surround the MST file with double-quotes.  This is one of the reasons that I saved the files with the names that I used above.

Here is your before and after...


When you are satisfied, click Next to continue to the Applicability Rules screen.


What did we just do?

We have selected the type of installer (which determines the necessary command line parameters), the installer file, the transform file to be included, and then told that installer to use that MST file during install.


Applicability Rules Screen

Click on Add Rule and select MSI Rule as the format, Product Installed an the Type, and check the box for Not Rule.

Now paste in the Product ID that we copied from the previous page in the Product Code field.  Be sure to remove the curly braces so that the format matches up with the example.  The rest can be left blank.

Click OK to save the Rule, then click Next to move to the Installed Rules Screen.


What did we just do?

We just created a rule that asks the Windows Update Agent to check to see if a package with Package ID {E59C88B3-8C59-43A0-846D-B8AFC36D78C6} is installed on your computer.  If it's NOT, then the package that we're making now is applicable to be installed.  In essence, we said, "if the Orion Agent isn't already installed, it can be installed."

Installed Rules Screen

Lastly we need to define the rules for how we detect if the new package is already installed.  There are many ways to check to see if a package is installed.  You can use any rule that you like (MSI Rules are a popular selection), but I chose to use the File Version with Registry Value for this example.  The Installed rules are how the Windows Update Agent determines if an installation succeeded.  For this package, we'll only go semi-complex.  Other examples within the catalog are much more complex and I encourage you to look at them for more details on how you can detect installation.


Many times, figuring out the appropriate registry settings for this process requires you to install the software on at least one machine so that you can dig down through the registry and file system.  I'll save you that step and just give you the information that you need to build the rule.

  1. As before, click on Add Rule, but this time select Basic Rule for the format and File Version with Registry Value for the Rule Type.
  2. In the Registry Key field, enter "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SolarWinds\Agent"
  3. In the Registry Value field, enter "InstallDir"
  4. In the Sub-Path field, enter "SolarWinds.Agent.Service.exe"
  5. In the Comparison Field, select Greater Than Equal To
  6. In the Version Field, enter the version number of the installer (in this case

You'll end up with what you see below.  Click OK to save the Rule and then Next to get to the Summary screen.


What did we just do?

This one is more complex than all the previous rules, so let's go through it a step at a time.  We just created a rule that asks the Windows Update Agent to check in the Registry for the key stored at "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SolarWinds\Agent" and extract the contents in the "InstallDir" value.  Then it takes the content from they registry key & value (C:\Program Files (x86)\SolarWinds\Agent\) and appends the "SolarWinds.Agent.Service.exe" to the end which yields C:\Program Files (x86)\SolarWinds\Agent\SolarWinds.Agent.Service.exe.  Then we extract the version from the file at that path.  Finally, it compares the version extracted from the file to that which we hand-entered in the rule.  If the value matches or is newer, then the software has been successfully installed.


Summary Screen

You are almost done!  I know that you've seen enough screenshots, so I'll be skipping the one here... yes, you're welcome.  If you want to add notes, do so and then click Next to actually Build the package.  When it's all done, you will get the a confirmation message - just click on OK.  That's it!  The package has been built!


Step 3 - Publish & Approve

Now this package is just like any third party update.  Just right-click on it and select Publish Packages.  Normally, you just keep the defaults and click on Next to publish it and click Finish to confirm it.  It's now been published to your default WSUS Server.


Finally, in the Patch Manager Console, move up to Patch Manager / Enterprise / Update Services / (Your WSUS Server Name) / All Updates.  Click on the newly created and published package.  Right-click on it and select Approve.  From here, you can determine which groups can get the new package and setup a schedule.  Like I said, treat this just like any other update from this point.


The Orion Agent is awesome!  What if I want to deploy now?!?

Patch Manager gives you that option as well!  Just right-click on the package within Update Services, and select Update Management.  Click OK on the "Update Management - 1 Updates" screen.  On the Task Options Wizard screen, you can add computers to the list.  Click on Next and choose the timing of the deployment and if you want schedule the update, configure logging, or add email notifications.  Click Next once more and then click Finish to complete the deployment.  The beauty of this is that if you try to deploy this package to machines where the update isn't applicable, it won't get installed because of the rules that we built together.  If you want to watch the installation process, you can go down to the Active Tasks to watch the Agent be deployed in real time.


Where can I get more information?

Like everything SolarWinds, I'd tell you to start on Thwack.  We've got the best user community bar none.  Just ask a question in the forums and watch the people come out of the woodwork to help.  We also have some excellent articles written up about the rules for custom update packages, troubleshooting the installation, and the logic of the Windows Update Agent.  However, If reading isn't your thing and you prefer the wonderful world of video, we've got Package Creation using SolarWinds Patch Manager and Package Creation Fundamentals videos for additional guidance.


And don't forget that one of the biggest resources of untapped information in Patch Manager are the packages that we already make for you in the Third Party Catalog.  You can use these as a resource for learning and building your own rules.  I encourage everyone to pop open a few of them to look into the way that we build the rules for each of them.  We've already done the heavy lifting for you with these packages.  Learn from us.  Now go forth and create your own packages!

With Web Performance Monitor (WPM) 2.1.0 just around the corner I'm happy to announce WPM 2.1.0 has entered Release Candidate phase. There are many improvements coming with this version, notably


  • Tighter integration with Server & Application Monitor (SAM) and Network Performance Monitor (NPM) to help you identify problems in your Web Application infrastructure faster
  • New integration allows you to
    • Create dependencies between Transactions and Applications and dependencies between Transactions and Nodes
    • Visualize the relationship and status of infrastructure components that can impact Web transactions
    • Visualize the relationship and status of Web transactions alongside node and application performance (New Transactions subview in Node Details page and New Transactions subview in Application Details page)
  • 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


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.


WPM 2.1.0 RC is available in your customer portal today. RC's are fully supported and upgradable to the final GA version (if it differs from RC.)


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.