1 2 Previous Next

Product Blog

26 Posts authored by: fcaron

We used to have an OS/SQL compatibility matrix for all product consolidated in this blog, but many of you have requested that we track this more formally, so here it is in a Success Center article: Windows Server 2012, 2016, and 2019 and SQL Server 2012, 2014, 2016 and 2017 Support


We are going to update this matrix as thoroughly as possible.


Feel free to continue to post your comments and questions about the matrix in this thwack blog post.


FYI, the latest and greatest versions for each products, are here

We have been keeping an eye on the discussions here asking for improvement in terms of network traffic analysis, beyond what MIB 2 (Interface traffic) and Flow technology (NetFlow, sFlow, jFlow...) have to offer.

And we recently saw that NBAR support was voted #1 enhancement request for NTA - the Network Traffic Analyzer (see more about SolarWinds Network Traffic Analyzer here)
As we were thinking about this, we wondered whether the requirement was basically for NBAR - period - or if this was the sign of a larger requirement for better tools to ananalyze your traffic.
For example, we did a Traffic Analysis survey, asking if you used DPI-type solutions and we discovered that a large proportion was using Wireshark (not really a surprise, but was a good confirmation) or any other form of DPI product
DPI solutions used by SolarWinds customers.PNG
Also, I recently talked to some of you and confirmed that a significant proportion (actually higher than what the above chart suggests) either had a Deep Packet Inspection (DPI) solution in place (Riverbed Cascade/Opnet, LanCope, ...) or had this in their budget for this year.
So all this fueled a lot of thoughts and raised some questions on our side, on which we'd really appreciate your comments and answers:
  • Does Wireshark meet most of your needs?
  • Do you need Advanced Traffic Analysis for environments other than Cisco, where solutions like NBAR may not be available? In other words, do you need a vendor-agnostic solution?
  • All of you who own a DPI-type solution, mentioned their (prohibitive) cost as an issue. We are convinced that you don't need to be an Enterprise, able to spend $200K or more on these solutions, to really need them. Small and medium-size businesses also encounter challenges with their traffic which require deep analysis.
    Is it time for SolarWinds to commoditize that market and offer 80% of those features for 20% of the cost?

Before I'll let you go and express your thoughts and describe your experience, here is a bit more on how we think about this problem.

What are the needs for Advanced Traffic Analysis?

We see mainly 4:

Breakdown my traffic by application and user, like Netflow does ... but better

As convenient as Netflow technology is, it actually does a pretty average job at identifying your applications (unless you deploy Flexible Netflow):
    • Limited to static ports. Any app using dynamic ports will be invisible to (Net)flow technology
    • Ignores that many application use port 80 to go through firewalls and are actually NOT HTTP / Web applications
    • Is unable to identify reliably true Web applications: either because (Net)flow does not inspect the HTTP header and does not do URL extraction. Also, content networks such as YouTube.com (owned by Google) are identified by the Content Distribution Network they use as opposed to the Web site they really have (e.g. 1e100.net for YouTube.com...).
      See this typical question we have, pointing to this great post explaining why (Net)flow is really not the ultimate weapon and why Flexible Netflow is not the panacea either.


I need an aggregated view of the Quality of Experience rendered by my applications to my users

In a perfect world, users experiencing slowness in their application will open a ticket or send an email, and IT will know about it. But the world is not perfect and how many IT engineers discovered the hard way, as they were thrown under the bus by an email from a user to the CIO, that the QoE offered by IT is actually not that great, despite what they thought?

Of course there are solutions to simulate users connecting across the network (E.g. SolarWinds VNQM, based on Cisco's Ip SLA technology) as well as simulate the details of their transactions on their mission critical applications (e.g. SolarWinds WPM), but those are based on simulations and do not reflect the true experience of users.

Wouldn't it be great to have a dashboard looking at the traffic of all your users connecting to their applications and calculate the latency they REALLY experience and reporting this in near real-time, or on a daily, weekly, monthly, quarterly basis?


I need help troubleshooting slow access to applications

Your users are complaining about slowness when accessing some application? (or a QoE dashboard, as presented above, is keeping you informed about that)

The first things people do is use the basic tools they have, to try to troubleshoot:

    • Look at saturated interfaces that can explain slowness. Then go to  (Net)flow information to understand the nature of this traffic and see what non mission-critical traffic could be removed to avoid the saturation moving forward. The problem with this, is that a) it's not always easy to identify all interfaces on the path from the impacted user(s) to the application and b) excess of traffic is not always the cause of the slowness
    • Look at the devices along the path - from the switch the user(s) is(are) connected to, up to the server this application resides one, via all WAN routers - and see if any experience poor health explaining the slowness (CPU, memory, IO...)

Decent start, but what if this does not answer the question?

What if it's a mis-configuration? What if it's one particular transaction of this application, out of dozen, that is slow, how do you figure which one? What if the slow application is actually spread across multiple-tiers (application server, database, storage...) and what you thought was a "simple" analysis of the path between the user and the application server, happens to be more complicated and involve several back-end servers?

All these more complex but unfortunately real-life examples, are almost impossible to troubleshoot with the basic tools.


Security is key for us and I need to know exactly what peole do on my network

Who is accessing internal file shares? From the outside of my network, really?

How about browser-based file shares (e.g. dropbox)? Is last amount of internal material being copied over to those?

Are your users downloading copyrighted content from P2P media and storing it on company-owned asset, e.g. their workstation?

Do you have unusual traffic from unexpected countries? What is this traffic about?

You already have an Advanced Traffic Analysis (e.g. DPI-based solution)? Tell us what you think about it...

  • What use case(s) does it meet for you (from list above or other)?
  • Do you consider it cost effective?
  • How important is it to have these products integrated to platform such as an NMS / IT infrastructure management platform such as Orion?
  • Would you consider a solution integrated to Orion that would address your most important need at a fraction of the cost? Or do you need the full power of those expensive solutions? Tell us what the minimum bar is!


How does encrypted traffic impact the effectiveness of your Advanced Traffic Analysis (e.g. DPI-based solution)?


If you currently run some form of Advanced Traffic Analysis product (e.g. DPI-based solution), how does encrypted traffic impacts it.

Did encrypted traffic dictated where you deployed your packet capture probes? Are there areas of your network that carry encrypted traffic that you are blind on due to that?


Sniffing traffic, ok, but which one?

Let us know about your most important traffic types, on which to perform Advanced Traffic Analysis:

  • A) LAN traffic on corporate / Data Center (internal)
  • B) LAN traffic on remote site
  • C) WAN traffic (general)
  • D) WAN optimized traffic (e.g. Cisco WAAS, Riverbed, Bluecoat)
  • E) VM to VM traffic
  • F) Load balanced traffic (e,g, Cisco ACE, F5)
  • G) Virtualized traffic (e.g. analyse traffic in/out of an application hosted by a Cloud SP)
  • H) DMZ traffic


Sniffing traffic, ok, but how?


Agents, span or Tap or RITE?

  • The agent-based technique is about running agents on the OS - virtual or not - that hosts your mission critical applications. If your focus is the traffic that goes to your applications (as opposed to look at all traffic including the fully meshed opne that goes across all your sites sites), then agents are a good solution because they make the 3 techiques below unnecessary, but they require an invasive action on your OS by adding a component to it: what CPU/memory do they consume on the OS? Are they really only looking at the traffic? How do we upgrade 100's of them that are deployed on yuour server farm...
  • The Port Spanning / Mirroring technique is basically about high-jacking one port from your switch and dedicate it for mirroring all or part of the entire traffic of the switch. Then the management product listens to packets from this port and performs analysis, storage...

Pretty simple, because most switches support this now, just a commend top issue and a cable to connect and you can start drinking from the fire hose; but may have an impact on the switch and can't guarantee 100% packet captured on very heavily loaded switches.
Note that spanning a port is possible on a HW switch but also on a vSwitch within a virtual environment

  • Network Taps are basically pieces of hardware that you buy to replace the switch for this function (capturing packets). They are placed inline and have no influence on the switch and pretty much capture 100% of the traffic.
  • RITE - Router IP Traffic Export, is a Cisco technology like spanning a port on a switch, except that it's done on a router. Again, easy to deploy since it leverages an existing device, but it impacts it and won't work great at high speed. See this nice and short blog post


Tell us about your experience, your preferences, what's allowed and not allowed on your networks, as far as capturing packets for Advanced Traffic Analysis.




...and avoid mistakes when updating your configurations.

When performing an address change on your servers (e.g. due to reorganization of your data centers, virtualization, consolidation...), you will have to reflect these changes in your firewall configurations. Depending on how large and numerous your firewall configurations are, locating the firewall(s) to change and finding the places in their configuration that need updating, can be tedious and error prone.


This blog reflects a fairly frequent real-life use case, and explains how FSM - Firewall Security Manager - can help making these changes quickly and safely, by double checking them before they are put in production.

The concrete example will be to detect where to make changes so that the IP of 2 servers can be changed for the new addresses:, while keeping the protection of your firewalls in place.


Finding the firewalls impacted by the change

The Query/Search Rules function searches in the configurations of your firewalls, even within subnet masks. Note that a simple text search in your configs will usually not be efficient because a) it would not find the address you are looking for, within a subnet definition and b) searching on the beginning of the address, e.g. 192.168.253 could return 100's of hits in a real life config.

FSM Rule Query.PNG

The blue window shows how to define the query.

Note that in order to avoid finding all the rules that have ANY in the searched parameters, check the box at the bottom of the window.

Then select all firewalls in your inventory (left portion of the pain window) and run the query.

We recommend saving it before the run (notice the Saved Queries tab at the bottom left corner)


FSM finds the impacted firewalls, and the objects to modify in their configurations

FSM Rule Query finds impacted firewalls and objects.PNG

The result will show up in a new tab on the right, and will contain one sub-tab per firewall vendor that contains the searched address. In this example, we will focus on the Cisco Firewalls tab, but in reality, you would have to check all vendor tabs.

In this example, the Cisco firewall HV-FW-01 contains a destination network object called Servers_in_Public_DMZ (used in a rule that appears in config line #570) that refers to 2 addresses that we are trying to change: .34 and .35.

The statement to change is, that "contains" .34 and .35


Preparing the change by using the Change Modeling session

A change modeling session is a very convenient feature that creates a safe environment (basically a copy of your production configurations) that you can use for all your tests and changes, without affecting your production configs.

Select the impacted firewall(s) that you identified with the above steps and click Analyze Change / New Change Modeling Session, and name your session (e.g. Server IP Change session)

FSM Change modeling session.PNG

Notice the new TAB on the right (this is your testing environment), that contains a copy of the config tile (config.txt), routing tables, and the tools available to test your changes (icons on the right)


Performing the changes

Double click on the config.txt to open a text editor that you will use to modify the configuration.

Search (CTRL F) for the impacted network object: "Servers_in_Public_DMZ" and modify this section:


object-group network Servers_in_Public_DMZ

network-object host




as follows:

object-group network Servers_in_Public_DMZ

network-object host





Then save your new config.

At this point you have impacted the copy of the config that sits in the Change Modeling Session, but not the main version of the config within FSM.


Verifying that the changes are valid

You have several tools available, that you can launch via the icons on the right, to test the impact that you have made with your change.

In essence, all these tools highlight the differences between the main and copied/modified versions of the versions.


We will focus here on the Compare Rule/Object tool.

The result is an Excel report that is generated within the Change modeling session:

FSM Change modeling session details.PNG

Open the report and look at the different tabs:

  • Rule Compare reminds you of the change that has been performed at the rule level (on line 570, an ACL statement is impacted because the destination Servers_in_Public_DMZ has changed)

FSM Change modeling session details - Rulle diff.PNG

  • Network Object Compare highlights the changes that happened to the modified Network Object: Servers_In_Public_DMZ in this example. Red denotes removed lines and green is used for added ones.

FSM Change modeling session details - Object diff.PNG

  • Traffic Flow Compare confirms that you have removed and added the expected traffic, so the traffic to the new server, after the IP address change, remains unchanged

FSM Change modeling session details - Flow diff.PNG

You can find more about this report here.

Putting these changes in production

Now that you are comfortable with these changes, click on the Generate Change Scripts tool on the right side of the Change Modeling Session window.

FSM Change modeling session details - Script.PNG

Here is what the generated script looks like, in this example:


!-- Object <Servers_in_Public_DMZ> Change summary

!-- Modified object

!-- Deleted member

!-- Added member

!-- Added member

!-- Added member

object-group network Servers_in_Public_DMZ




no network-object

!-- ACL Rule Change summary

!-- Modified rule

!-- Modified destination Servers_in_Public_DMZ

!-- No change command needed as this is an indirect change caused by modifications to object/object groups used in the ACE.

!-- access-list outbound extended permit tcp object-group DM_INLINE_NETWORK_14 object-group Servers_in_Public_DMZ object-group DM_INLINE_TCP_3


After you review the proposed changes, you are ready to put them into production by executing these commands in the firewall console

If this device was managed by NCM (not the case in this example), you can actually execute the script via NCM (right click menu Execute Script), so you don't even have to connect to the device console (NCM does it for you)

FSM Change modeling session details - Script exec.PNG


You can then use this button to update the configuration into FSM, from whatever source it was taken from - NCM or the device itself - and make sure that your changes were taken into account.

FSM Update configs.PNG


I hope that was helpful and would really welcome reading your FSM use cases - does not have to be that detailed :-) .

[thanks to Lan Li, FSM dev, for his contribution]

Here is a great way to interact with SolarWinds experts and ask questions about products and see demos.

It's called "thwackCamp", it's free, you just need to register here: SolarWinds thwackCamp

More information on SolarWinds thwackCamp


If you missed the event, here are the recordings: http://solarwindsthwackcamp.com/#/webcast

You'll need Flash installed to watch them.


The sessions covered were:

  • Keynote Kickoff
  • How to use the SolarWinds API and SDK
  • Effective VoIP Troubleshooting using CDRs and IPSLA Operations
  • Advanced Alerting and Report Techniques in SolarWinds NPM
  • SolarWinds NPM November Release Preview
  • How to Identify Specific Network Behavior Using NTA
  • Thought Leadership session: BYOD and MDM
  • Secrets of SolarWinds SAM
  • Top 10 Things Logs Can Do for You, Today
  • Managing Performance in Virtual Environments
  • Using WSUS or SCCM to Roll Out 3rd Party Patches
  • Best Practices for Managing your IT help desk
  • How to Monitor your Network, Active Directory or VMware on the go
  • Toolset Deep Dive: 10 Overlooked Tools and Their Uses in Engineer's Toolset
  • Always Available Applications: How To Achieve This Goal with SolarWinds SAM and SEUM
  • Managing Storage Performance in Virtualized Environments

You told us that you were involved in Cisco (or non Cisco) ACL management and needed help.

Check-out all these requests that you posted on thwack, for a better management of Cisco (and non-Cisco) ACL's.

ACL Management


Has anyone integrated the Athena  FirePAC into your Orion NCM?  Need some advice

ACL hits in NPM for Cisco ASA

Re: Cisco ACL Manager







Help has arrived, it's a new product in the SolarWinds portfolio, it's called FSM: Firewall Security Manager.

Here is a more detailed blog post about FSM.


If you have ever banged your head against the wall, after staring at pages of ACL statements, trying to predict what your firewall or router will do, or understand why this traffic does not go through... or actuall does goes through... this product should amaze you.


Let us know of your thoughts

What is Firewall Security Manager (FSM)?


FSM is a new product, now part of the SolarWinds portfolio, which can perform analysis and reporting around security rules that are in your firewall and router configurations.

Even though the product is called “Firewall Security Manager”, it is also very much applicable to the security rules of your routers.

So think of “Firewall” as the function and not the device.

FSM has tremendous value, not only to perform firewall - the device - config analysis, but also does a great job looking at your router’s firewalling features such as ACLs and NATs…


FSM supports the following devices:

• Cisco Security Appliances: PIX, ASA, FWSM, ASA 8.3

• Cisco IOS routers: Version 12.0 to 12.14, excluding X* Series

• Juniper firewalls: Netscreen, SSG, ISG

• Check PointTM products: SmartCenter NG/NGX, Security Management R70

• Check PointTM platforms: SecurePlatform, Check Point IPSO (formerly Nokia), Crossbeam, Linux, Solaris


The product can be run standalone, or integrated with SolarWinds Network Configuration Manager (NCM). More on this integration here.

It’s worth mentioning that FSM is a feature rich product, and this blog post covers only the main features of the product.

But before we look at those, let’s talk first about whether it’s for you.


FAQs: Who is Firewall Security Manager (FSM) designed for?

If you are more or less involved in firewalling, FSM is for you, but here is more detail, depending on what situations fits you best:

  • I already own NCM, so why do I need FSM?
  • Firewalling and security really are not my forte, how can FSM help?
  • Security is my bag already, what does FSM buy me?


I already own NCM, so why do I need FSM?

  • You spend time around security statements in your configs, and you find them very hard to read, making them difficult to understand and risky to modify.
  • Security statements in your configs have a long history and/or are modified by several people.

As a result, they are convoluted, redundant and sometimes possibly conflicting.
You need to clean and simplify them, without impacting the traffic.

  • You need security reports to advise you on the current security level of your configs and advise you on how to improve, above and beyond the compliance checks of NCM.
  • NCM is great for helping you roll-out an ACL or NAT change, but does not understand the effect that this change will have on the traffic.
    In addition, the traffic on an end-to-end path is impacted by the combined effect of multiple firewalls and routers, and you need a tool that helps predicting the impact that one or more combined changes can have, from an end-to-end point of view.


Firewalling and security really are not my forte, how can FSM help?

  • You need expert advice on firewalls and routers security so you don’t have to spend time becoming proficient in standards such as NSA, NIST, SANS or PCI or creating firewall compliance checks completely from scratch.
  • You need a safe environment to experiment your changes, try several scenarios, and predict their end-to-end effect BEFORE pushing them live.
    When you are satisfied with the predicted behavior, you want assistance in implementing these changes, and be able to roll back easily in case of problem.


Security is my bag already, what does FSM buy me?

  • Even though you are proficient in this area, security is a complex domain and you’d like a tool that could help double check you work before your deploy to production.
  • Auditors and/or security meetings require frequent reports on your current security levels and creating these report manually is an arduous task you’d love to automate.
  • Your network is complex and you find it difficult to predict the effect of a change in firewall security rules, from an end-to-end perspective.
  • User requests are driving you to make frequent changes to your security objects and you need a simple but effective change management process, allowing your users to request changes via a simple Web interface, which you can then review, implement, test and deploy.


Under the hood: What can Firewall Security Manager (FSM) do?

ACL editor that improves readability

Most of the time, before you do anything, you need to deal with already existing security rules.

A lot of security rules.

So readability is the first thing FSM will help you with.

With FSM, your visibility will upgrade from this type of view (basically text file):

ACL editor raw view.PNG  to this ACL editor Firewall Security Manager view.PNG

Notice the different tabs, which give you clear visibility on your ACLs (Security Rules), NAT Rules, Network Objects…

And if you are still emotionally attached to the long, disorganized and sometimes messy blocs of text in your configs, no worries, they are still there in the Native Configs tab:


ACL editor raw view in FSM tab.PNG

For more, take a look at the on line demo or, as always with SolarWinds product you can download a free evaluation copy here.


Ok, this is cool, but what about the “expertise”, that was discussed at the beginning?

Read the sections below.

Access Control List Cleanup


Let’s take a “simple” example to illustrate how FSM can help in this area:

ACL cleanup raw configuration.PNG

Unless you are doing this 8h per day, it might not jump at you that there are redundant and therefore useless rules in this extract of a PIX firewall config.

Before your head hurts, let’s see below what the FSM Cleanup report advises you to do.

ACL cleanup report extract.PNG

Line 106 is identified as redundant to preceding rule 93, which allows FTP access from all addresses.

Clearly rule 93 will match any packet that rule 106 might match, and so rule 106 never gets triggered.

Consequently it does not contribute to the behavior of the firewall and can be removed.


Was too easy? Let’s take a closer look at line 83 and its interaction with lines 80 and 81.

ACL cleanup report extract shadowed rule.PNG
Are you noticing something? FSM does!
FSM’s Cleanup report tells you that 83 is shadowed by 80 and 81.

Rule 83 is allowing a group of mail services.

It is identified as shadowed by the combination of the two preceding rules 80 and 81.  These two rules will match anything that rule 83 might match and therefore rule 83 does not contribute to the behavior of the firewall and is a candidate for being removed.

This seems like a redundancy case, but rule 83 is actually marked as a "shadowed" rather than "redundant" and this means that the permit action at rule 83 conflicts with the deny actions of rules 80 and 81.

This indicates that there be some intention on the part of the firewall administrator that is not being carried out here.

It turns out that rules 80 and 81 were inserted for a debugging purpose and that purpose is now long past.

The correct action here will be to remove rules 80 and 81, thus restoring the “deny” at rule 83.


Configuration Security Audit

Now that your configurations are cleaned-up and optimized, are they safe? Are there security holes in them?

This is what the FSM Audit report will tell you.

Security Audit reporting.PNG

For example, check C31 indicates that mail services were allowed from the Internet to the internal network.

Since the mail server is on the DMZ, it is disturbing to see mail services allowed into the internal network.

Click Details to understand more about what rules create the C31 security risk.

Security Audit reporting details.PNG

To find out even more about why the combination of these security and transaltion rules create the risk, you can click the rule numbers and understand the full detail, and more importantly, teh recommendation.


Change Management

FSM has many features in this category and it would be too long to describe them all here, so let’s just briefly describe a few:

  • Configuration Diffs highlights all changes in subsequent versions of your configs (FSM keeps the history)
  • Change Advisor has a web interface that allows your network users to submit config change requests. These requests can then be reviewed by network engineers/firewall administrators, implemented, tested before they go live and then, be pushed in production.
  • You even have a Change Modeling environment, that makes copies of your configs in a special context called a “session”, which you can use to prototype any number of changes, without touching your master versions of the configs (those that currently run in the devices).


But let’s focus a bit more on one of the most spectacular change management features of FSM: Packet Tracer!

There are 2 main use cases for packet tracer:

  • You are making a change in your security rules, and you want to be sure that you are not inadvertently breaking connectivity between 2 points of your network.
    Have your configs reviewed by FSM, and get a prediction of whether or not your config changes will do something wrong, before they go in production.
  • Somebody comes to you and asks for help figuring-out why a portion of your network can’t exchange some type of traffic with another area.
    Have FSM look at the end-to-end path between these 2 sites and tell you what happens.


Now that you understand the use cases: here is the only input you need to give Packet Tracer before it can do its magic:

ACL change management virtual packet tracer input.PNG

The result is an assessment of a) whether or not the packets will cross the network between the 2 specified addresses and b) if not: it will tell you why and where they are blocked.

Basically FSM’s Packet Tracer understands how security & translation rules, as well as routing tables and VPNs interact with your packets, and predict connectivity (or lack of).


And it does this, without injecting test packets on the network or sniffing the network.



  • Less config mistakes.
    Ever heard the statistic that 80% of network faults were not HW issues but config changes not properly controlled and understood? Here is a product that will help you in this regards…
  • Faster troubleshooting.




Hopefully you got the point: FSM is a very feature rich product and brings you tons of expertise in the firewalling area (firewall and routers).

It has many other features that we’ll discuss in future blog posts.

In the meantime, you can download a free eval of FSM here, and see by yourself!


Like always with SolarWinds products, it installs super-fast and provides value in less than 1 hour.


NCM integration


If you have read the above, it should be obvious that FSM is a very natural extension of SolarWinds Network Configuration Manager (NCM).

The good news is: they are already integrated (NCM v7.1 recommended)!

  • FSM can get device configurations directly from NCM’s database. No need to duplicate those configs in 2 separate products.
  • FSM can execute changes (e.g. cleanup scripts) on devices via NCM’s scripting feature. You maintain your device credentials in only one product and not 2.


Install both and you really have a best of breed platform to rely on, as far as managing your firewall and router configurations!


Once installed, it takes just a few clicks, before you can get tremendous value from FSM.


Want to try now?


Download the FSM evaluation copy here, you can do all this in less than 30 minutes.


Once the FSM client is started, click on this icon

FSM import button.PNG

Then select the NCM import option, give the NCM URL and admin credential, select your NCM nodes from the list below (don't select those that have type=unknown, and prefer those that have ACLs in their configs)


FSM integration with NCM.PNG


Hit Finish and you will see your FSM Inventory tab (left panel) populated with your firewall and router devices.

Their configs are now in FSM, you are ready to start.

The best way to see what the product can do is eirther to explore or look at the Online demo.


Note that in terms of adjacencies with other SolarWinds products, FSM is also very close to LEM, the Log and Event Manager, so you might be interested in taking a look at LEM too!




Here are the main FSM resources: Online demo, home page, evaluation download, thwack area, prices, HW&SW requirements, FAQs


Are you a new user of SolarWinds NPM? Could you use a refresher of the product basics?


If so, join SolarWinds for a level 1 NPM customer training.


This training will include:

- The basics of monitoring technologies

- Understanding monitoring for routers, switches, servers, and other infrastructure

- Alerts! Making the most of your performance and availability monitoring

- Optimizing NPM features


Register NOW for this live event on Thursday, July 12th, 2012 from 11:00 AM - 12:00 NOON CDT: https://www1.gotomeeting.com/register/342337152.







This blog complements the information available here, related to what SolarWinds has to offer to the Managed Service Providers (read also the FAQs) and focuses on the multi-tenancy capabilities of SolarWinds NPM network monitor (even if some of this document is actually applicable to other products relying on the SolarWinds Platform, aka Orion Core.

First, what is multi-tenancy?

Wikipedia defines it as a software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). Multi-tenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations.

With a multi-tenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance.

The drivers behind multi-tenancy are mainly (but not only) cost savings (only one platform – HW and SW – is needed to support multiple customers) and easier release management (tasks like upgrade, high availability, database backup are performed only once and benefit all supported customers in a single operation).

Can SolarWinds products be deployed in a multi-tenant way?

Yes, and here is how.

For more clarity, let’s break down this discussion into 2 separate topics:

·         Visualization
How do I configure SolarWinds
products so a particular customer can safely login into the SolarWinds product portal and get a view restricted/limited to THEIR IT resources, even though they are being supported by a multi-tenant platform that also supports other customers like them?

·         Deployment and Data Collection
What should be my deployment strategy, so I can collect management information from my customer’s IT environment and feed it back in to a single shared (i.e multi-tenant) SolarWinds
instance? How do I deal with duplicate IP addresses that my customers have?

This discussion could be extended to other levels, such as storage, and this might be explored in further editions of this blog, but for now, let’s stick to this two main topics: visualization and data collection.

Configuration of the visualization in multi-tenant environments

How to create for my customers, the perception that they are on their own private IT management platform, while they are actually being hosted on a single instance, shared with other customers?

The SolarWinds platform provides two types of “Limitations” that will allow you to isolate the view and the data that each customer has access to:

  • Account limitations.
    This type of limitation is the most commonly used by MSPs and allows for the restriction of the Nodes that a given login will be able to view (or not). Simply put, the Account Limitation controls visibility that Accounts/Login have of Nodes. We will use this notation in the rest of this blog: Account => Nodes
  • View Limitations.

This type of limitation allows the MSP to restrict the Nodes that a given View will be able to display. This will be noted View=>Nodes. Of course, if all your accounts have access to the same Views (e.g. a TOP 10 view), this is not very helpful in the context of isolation, because then all your accounts will have access to all the nodes that this view has visibility on. This is useless for multi-tenancy, unless you can control visibility of Accounts on Views (Accounts => Views); then by combining this with Account Limitations above, you can configure this type of visualization model: Accounts => Views => Nodes.

What is a View?: A view is an HTML page displaying multiple resources (single graph, table, display widget), that have a common theme. A product usually comes with multiple out of the box views. Customers can create new or customize views. Views are selected by clicking on their names right below the product tabs.


Now that we understand the theory behind these 2 features, let’s look at concrete examples and how to configure them.


Account limitations: As said above, MSPs typically use this to control the Nodes visible by their Accounts (i.e. login) across all generic views (or regardless of the view).

To configure Account => Nodes, go to Settings>Manage Accounts>Select an Account>Edit>Account Limitations>Add Limitation:



As you can see, there are many different ways to express the list of nodes that will be visible by the account/login that you have selected. Let’s explore a few:

  • Single Network Node does what you would expect (you can select a single node). Easy for testing but fairly limited.
  • Group of Nodes (understand “list” of nodes), is more interesting: it proposes the list of Nodes so you can check one node or multiple nodes that your Account/Login will have visibility on. This is the most commonly utilized.
  • Single Group allows you to define a group and use its content to limit what a user shoud be able to view. This is an easy way for an MSP to define the views of each of their customers.
    Just create a group (Settings>Nodes & Group Management>Manage Groups) and use this group to configure your Single Group limitation.
    Any user associated to this group, will see his/her views restricted to the content of this group.

    Note that this was fixed in NPM v10.4, and used to be more tricky in previous versions , because it does not do what most people expect. Here is the behavior experienced pre-v10.4 abd how to workaround it. This section below is NOT required in NPM v10.4.

You would expect it to give visibility to all Nodes that have previously been put in a group, which would be very easy for MSP’s: put your nodes assigned to each customer in a group representing the customer and you are done, then just assign each Customer groups to the Account/Login allocated to this customer.
Unfortunately it does not work this way. Doing this restricts access to the Group itself but the visibility limitation does not extend to the content of the group. So this does not help you.
Here is how to make it work: make sure you have a Custom property for each Node in NPM network monitoring software, populated with the Customer name (you would probably do this to create the group anyway), but instead of creating your Account Limitation based on the group (which does not work), you create it based on a Custom Account Limitation based on a property. Creating a Custom Account Limitation based on a property is easy: Start Menu>App Programs>SolarWinds Orion>Grouping and Access Control>Custom Property Editor>Orion>Account Limitation Builder> Add>name your custom limitation, select your Custom property (e.g. CustomerTag in example below):
Once done, go back to your Account Limitation screen and notice your Custom Account Limitation method:
This is functionally equivalent to what you think it would do if you created your Account Limitation to a Group that was based on the Custom property “CustomerTag”. Just don’t use the group.


View Limitations: As seen above, MSPs typically use View limitation in this context: Accounts => Views => Nodes, and the most common use case is when Views are actually Home>Summary Views that need to be different per customer, because they have maps that are specific to customers. In other words, for the map to be specific to a customer, you need to create a view that has the correct map and assign it to the Account / Login attached to this customer.




Here is how to assign a Summary View to a account: go to Settings>Manage Accounts>[select an account]>Edit>Account Limitations>Default Menu Bar and Views:



Then, once you have assigned a view to your account, you can now restrict what Nodes will be visible from this view by using a View Limitation: Settings>Manage Views>[your custom view]>Edit>View Limitation> Edit:


From there, the same discussion as above applies.


Let’s take a concrete example and make sure you understand how the system behaves. Let’s say you have used this model Accounts => Views => Nodes to deploy your 2 customers ACME and EuroCust, respectively based in US and Europe, as follows:

  • Account ACME => US_View – use the home page view configuration
  • Account EuroCust => Europe_View – use the home page view configuration
  • US_View=>Chicago_Router, Austin_Router – use the View Limitation feature
  • Europe_View=>Frankfurt_Router, London_Router – use the View Limitation feature


This will provide the expected view, but you will want to know about the following behavior of the system: If the Account ACME user can modify the URL of his US_View page and figure-out what URL corresponds to the Europe_View page, he will not only be able to see the map of Europe (not big deal) but more importantly, see the Frankfurt_Router, London_Router, because these are attached to the Europe_View, as per the View Limitation.


If you are afraid of this behavior (some MSP consider this a back door), then you should NOT use the View Limitation and rather model your system like this:

  • Account ACME => US_View – use the home page view configuration
  • Account EuroCust => Europe_View – use the home page view configuration
  • Account ACME => Chicago_Router, Austin_Router – use the Account Limitation feature
  • Account EuroCust => Frankfurt_Router, London_Router - use the Account Limitation feature

The conclusion of this part is that you will want to think about how you will model your environment and customers, do some preliminary testing of SolarWinds products, based on the ones that you have deployed. Remember that different products may honor the Account and View limitations differently.

Ultimately, you will want to make your own opinion about the pros and cons that the various options offer. Hopefully the section above will help you understand the most important points, so you can figure out the details related to your particular environment.



Deployment and Data Collection in multi-tenant environments

The main issue at this level is dealing with duplicated IP addresses, which the MSP customers will usually have. Today, there are two recommended ways to deal with this: NAT and EOC-based deployments

NAT-based deployment: Network Address Translators translate the customer domain addresses, so that they are all unique from a SolarWinds product perspective. Basically, NAT eliminates the overlapping IP addresses.

Note that this makes the identification of managed devices more complex because the translated IP’s don’t necessarily make sense to report readers. This can be addressed by populating custom properties with IP’s or Names that will not be affected by any translation.



EOC-based deployment: a full instance of SolarWinds product is deployed per Customer (usually large ones) and they are consolidated at the MSP level, by EOC (Enterprise Operations Console)


Other deployment considerations

SolarWinds does not recommend the deployment of a central (NOC) instance of our network management product with one Polling Engine deployed on each customer’s network, because the WAN that would then connect the remote Polling Engines and the central database, would likely be the cause of lower reliability and higher latency which is not a certified environment.

Other solutions such as managing an entire customer environment via a unique IP address and differentiate their different managed devices (e.g. servers) using different SNMP ports (port forwarding) does not work.



You can find more on Orion architecture (non MSP-specific) here.

During this customer training session, we will discuss and demonstrate how to get the most out of SolarWinds Engineer’s Toolset. Here’s your chance to see how it works, get some pointers and to ask questions from the best! Join hosts Josh Stephens, Head Geek at SolarWinds and Matthew Harvey, Technical Support Representative as they demonstrate the power of Engineer’s Toolset.


We hope you like it.

As always, let us know of your feedback

We’re interested to hear what you think of CatTools. Tell us how you use CatTools on a daily basis. How has it saved you time? Effort? Your job?

Tell us your compelling stories and daily deeds, and you’ll be registered to win one of three great prizes!

  1. iPad 3
  2. Kindle Fire
  3. iPod Nano

The survey will only take about 10 minutes of your time. We’re looking forward to your feedback!

After the release of NCM v7 (and 2 service releases 7.0.1 and 7.0.2), here is what the NCM team is working on now, for the future of the product.

The main theme is performance and scalability:

  • WEB UI performance improvements. We are hearing the feedback coming from many of you, that the NCM WEB interface is not as fast as the Win32 application is.
    We are also conscious that many cannot allow their users to RDP into the server in order access the NCM UI, for security reasons.
    So the general move to the WEB continues but with a lot of attention being put on improving the performance of the already existing WEB UI as well as making sure that every new WEB UI developed, approaches the performance of the Win32 application.
  • Performance Improvement related to Inventory
  • Improve the Database purge and cleanup activities to avoid performance degradation over time, due to clogging of the database and disk directories with downloaded configurations
  • Support for Additional polling engines to increase the number of manageable nodes or distribute the load across multiple polling engines.

Other improvements include (but are not limited to):

  • More native device support (e.g. Alaxala, Apresia)
  • The “Settings” page is moved to the WEB
  • The Real Time Change detection (RTCD) feature is easier to configure
  • Inventory-related improvements (incorporation of inventory reports from thwack, better Juniper Inventory reports, …)
  • Config Change Template scripting language improvements (e.g. string parsing and manipulation) to reduce the need for external scripting

PLEASE NOTE:  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.


A few tips on NCM 7.0.2

Posted by fcaron Mar 6, 2012

Some of you have commented than NCM 7’s new architecture, leveraging Orion platform (aka Orion Core), changed a few important things, especially how they were integrating NCM with NPM and how they were adding nodes to NCM.

Our response to this, was in NCM 7.0.1 and is in NCM 7.0.2.

This blog post recaps most of these enhancements, especially those in 7.0.2 that was release today (Mar 6, 2012).

NCM 7.0.2 offers more granular control of the NCM-NPM integration:

If you are not familiar with NCM 7 deployment scenarios, we recommend to read NCM 7.0, 7.1, and 7.2 Architecture and Deployment before reading further

Some of you have commented that NCM 7.0 did not offer enough flexibility in regards to the integration of NCM and NPM. In particular:


  • When NCM 7.0 is installed on the same server as NPM 10.2, the NPM users now necessarily see NCM tabs and resources.

    With NCM 7.0.1 (included in 7.0.2),  it is possible to configure an Orion user account (e.g. an NPM user) in order to have no visibility of the NCM resources, by using the new NCM User Account setting NCM Role=None. See the NCM admin guide section “Setting User Account Access”, for more details.


    Note that it is also possible to remove the NCM Configs tab by configuring your Orion user like this:


  • NCM nodes imported into NPM/Core database are necessarily polled by Core (Node status and Statistics polling)

    To address this, we have made it possible in NCM v7.0.2, to slow down considerably the frequency of status and statistic polling for the nodes that are not supposed to be monitored, so they don’t generate any significant load on the system.

    These 2 parameter’s value can now be set to a maximum value of 32767, which means status polling performed every 9h and node statistic polling every 22 days:


    One could think of setting the Polling method as “External Nodes” or “ICMP” to eliminate/lower the load, but the side effects are that these modes do not store SNMP credentials, which means that NCM will not be able to run Inventory reports effectively. Similarly, turning these nodes as “unmanaged”, will make it impossible for NCM to download configs or execute scripts.


    Usability of the NCM “Add or Manage Nodes” page has been improved

    We added “Edit Properties” and “Search” buttons as well as a more complete list of properties, usable to organize – “Group By” - the list of nodes (includes custom properties):



    Orion‘s API has a new verb which makes it possible to programmatically insert news node into NCM 7.

    An example of a script leveraging this verb is described PowerShell script that exports Nodes from NPM and imports them into NCM (for Core 2011.2.x and before - NPM 10.2 and before) and covers the use case of extracting nodes from an Orion database (e.g. NPM nodes) and inserting them into NCM 7.0.2. This can be used to replace the scheduled job that was used before to perform similar operations.


    NCM 7.0.2 has a new Custom Property that identifies “NCM only nodes”

    When you have a large amount of nodes managed by NCM, that you don’t want to manage with NPM, it is helpful to be able to identify them, in order to mass-change one of their attributes (e.g. polling cycle, see above) or group them. To facilitate this, the NCM 7.0.2 synchronization creates and populates a custom property called “Imported_From_NCM”, for all nodes that were in the NCM database before the synchronization and were added to the Orion database because they did not exist in the Orion/NPM database. For these nodes, the property Imported_From_NCM is populated with the value “true”.



    For more on 7.0.2, see the release notes

  • As our customers deploy more SolarWinds products, we see an increasing number of demand for a programmatic way to export and/or import nodes (as well as interfaces, volumes…) from/to an Orion instance.


    The combinations of products involved in these scenarios cover, but are not limited to combinations such as:


    • Export nodes from NCM and import them into NPM network monitor
    • Export nodes from your own CMDB and import them into NPM
    • Export nodes from your own CMDB and import them into NCM
    • Export nodes from NPM and import them into NCM


    This blog contains and describes a working PowerShell script example, that exports nodes from SolarWinds NPM network monitoring software and imports  them into NCM, but it can be easily modified to accommodate other combinations, including non-SolarWinds sources (CMDB)


    The required configuration to run this script is:


    • NPM 10.2.x or 10.3.x (different versions of the script are required, see below)
    • NCM 7.0.2 or 7.1.x (different versions of the script are required, see below)
    • SDK 1.3 or 1.4 or 1.5
    • Windows PowerShell (ISE is used in this illustration)


    The script for 10.2.x is located here:PowerShell script that exports Nodes from NPM and imports them into NCM (for Core 2011.2.x and before - NPM 10.2 and before).

    The version adapted for Core 2012.1 (comes with NPM 10.3) is here: PowerShell script that exports Nodes from NPM and imports them into NCM (for Core 2012.1 and after - NPM 10.3 and after)


    Here is an example of run, which extracted 561 nodes from my NPM 10.2.2 and imported them into my NCM 7.0.2


    • The upper panel of PowerShell ISE contains the script. The first 2 blocks define hosts and credential for your data source (NPM in this example) and target (NCM in this example). These need to be changed for your environment, of course.
    • The second panel shows the trace of the run. Should be pretty self explanatory.




    • After the run, the target system (NCM 7.0.2) had 561 more nodes. As you can see, the nodes added by the API, are “tagged” with a property called “ImportedByAPI”, so you can easily identify, group and mass-modify them if needed.




    A few features of the script:


    • Nodes that already exist (same IP) in the target system, are skipped. The trace will send you messages such as this:




    • The script as uploaded, actually ignores interfaces and volumes, but just because the 2 relevant sections are “commented out”. Look for sections like this and remove the If (0) {…} to enable them and start moving interfaces and volumes too (interfaces requires NPM network management software on both sides of the script, of course)




    • The script extracts all properties from the Nodes and copies them over to the target Orion.
    • If you run this script against an NCM 7 target, prior to 7.0.2 (i.e. 7 or 7.0.1), the added node won’t be manageable by NCM (they will just be in Core), you will need to add them manually to NCM, using the Add or Manage Nodes UI. NCM 7.0.2 has a new API verb that imports the node up to NCM, so it becomes immediately and automatically manageable by NCM. The last line of the script takes care of this:




    I hope you will enjoy and benefit from this script, and I don’t want to finish without thanking Tim and Tomas for their invaluable help!


    Try the 30-day free download of NPM and NCM network management software.

    This blog is a sequel of the previous Orion Architecture blog and focuses on the NCM 7.x architecture and deployment.


    NCM 7.x architecture is different from the previous versions, mostly because it leverages several components from Orion Core (see Orion Architecture blog) and integrates more tightly with Core-based products such as NPM.


    NCM 7.1 brought these additional changes:

    • Support for additional polling engines
    • Fresh installation does not allow for installing NCM integrated with Orion (e.g. NPM) on a separate platform. However, customers running NCM 7.0 integrated with NPM on a separate server, can upgrade to 7.1 and remain in this deployment type (integrated - separate server). As described in NCM 7.1 release notes, section "NCM 7.1 deployment types", the integrated-on-same-server deployment will be the only option in a future release.


    The recently released NCM 7.3 instroduces these changes:

    • NCM and Core/NPM databases have been merged.
    • Deployment scenario where NCM is integrated with NPM but installed on a separate server is no longer supported.
    • Please see NCM 7.3 Architecture and Deployment for details.


    Standalone deployment


    • Choose this deployment if you only have SolarWinds NCM or if you want it completely non-integrated to any other Orion-based product.

    • Other SolarWinds products can be installed and integrated to a standalone NCM at a later time.

    • Node, User Account and Syslog &Trap Management rely on Core components. NCM 7 also benefits from Network Atlas.

    • NCM 7.0 always relies on 2 databases

      • The “Core database” contains essentially the information related to Node and User Account. The “NCM database” contains all information related to device configurations
      • They can be hosted on the same or separate database servers. Here are a few diagrams showing NCM standalone with several possible database deployment options:


    image        image        image


    •   Watch a video of a Standalone NCM 7.0 deployment here



    Integrated Single Server deployment


    • Choose this deployment to optimize your hardware footprint for NPM and NCM
    • NCM 7.x always relies on 2 databases, see the Standalone deployment type for more information.
    • NCM 7.x can be co-hosted with NPM 10.x
    • In the future, this will be the only mode supporting NPM integration.


    In this deployment, both share the same Core.


    In this case, the Web UI is always integrated, i.e. Home/Network and Configs tabs appear side by side in the WEB interface. Note that it is possible to configure NPM users to have no visibility of the NCM tab and resources, with NCM 7.0.1, by using the NCM User Account setting NCM Role=None. See NCM admin guide section “Setting User Account Access”.


    In an upgrade scenario (E.g. NCM 6 to NCM 7 and NPM 10.1 to NPM 10.2), the nodes previously in NCM 6.x will be synchronized with the Core database and appear in NPM. If some of these nodes are to be NCM-only nodes, you can hide them from NPM users, by using account limitations. Orion Core will also poll them for status (up/down).




    In this deployment, the database location options are similar to the Standalone deployment, described above.


    •   Watch a video of a Integrated Single Server deployment here



    Integrated Separate Server deployment


    • Choose this deployment to optimize the scalability of your deployment
    • NCM 7.0 can be hosted on a separate server from NPM 10.2, and be integrated.
    • NCM 7.1 can be hosted on a separate server from NPM 10.3, and be integrated, but only in an upgrade scenario. A fresh installation of NCM 7.1 does not allow for this deployment mode. This deployment will be entirely desupported in a future version of NCM (i.e. upgrade won't be possible either). We recommend moving away from this config by moving your NCM on the same platform as NPM, if you want to keep them integrated.
    • NCM 7.3 no longer supports this deployment setup.


    In this case, the Web UI is always integrated, i.e. Home/Network and Configs tabs appear side by side in the WEB interface. Note that it is possible to configure NPM users to have no visibility of the NCM tab and resources, with NCM 7.0.1, by using the NCM User Account setting NCM Role=None. See NCM admin guide section “Setting User Account Access”.


    In this deployment, both share the same Core (Core-1 on diagram)


    The Core installed with NCM Server (Core-2 on diagram) is required for integration but won’t perform any polling activity. It can be used to receive Syslogs and Traps, for Real-Time Change Detection. Note that the Core-1 Syslogs and Traps (shared with NPM in this example), can also be used for NCM’s Real-Time Change Detection.


    In an upgrade scenario (E.g. NCM 6 to NCM 7.x and NPM 10.1 to NPM 10.3), and whatever your deployment type, the rules used for Real-Time Change Detection, must be reconfigured using the Core-based Syslogs and Traps server. See NCM admin guide section “Configuring Realtime Configuration Change Detection”.


    In an upgrade scenario (E.g. NCM 6 to NCM 7.x and NPM 10.1 to NPM 10.3), the nodes previously in NCM 6.x will be synchronized with the Core database and appear in NPM. If some of these nodes are to be NCM-only nodes, you can hide them from NPM users, by using account limitations. Orion Core will poll them for status (up/down).




    In this deployment, the database location options are similar to the Standalone deployment, described above


    •   Watch a video of an NCM 7.0 Integrated Separate Server deployment here



    Integrated Separate Server deployment – Additional Web Servers


    •   Choose this deployment to further optimize the scalability of your deployment
    •   The separate deployment of NCM can leverage 2 NCM Web modules


    One integrated with NPM and one (or more) integrated with an Additional Web Server




    In this deployment, the database location options are similar to the Standalone deployment, described above


    NCM 7.1 multi-poller deployment

    Multi-poller - Standalone

    • This is the recommended configuration for NCM standalone, leveraging multiple polling engines


    Multi-poller - Integrated Same Server

    • This is the recommended configuration for NCM integrated with NPM, leveraging multiple polling engines
    • The polling engines are shared by NPM and NCM



    Multi-poller - Integrated Separate Server

    • This configuration (NCM integrated with NPM on a separate server), is still possible in the case of an upgrade from NCM 7.0, but will be de-supported moving forward. It is not possible to install a fresh NCM 7.1 in this configuration.
    • The polling engines are shared by NPM and NCM
    • The notation (A, B, …H) reflects example of 8 nodes managed by NPM and NCM integrated, to describe the activities performed but the platform components, on each of these nodes
      • Devices A, B, C, are assigned to Additional Poller 1
      • Devices D, E, F are assigned to the Orion Main poller
      • Devices G, H are assigned to Additional Poller2


    • The activity performed on these 8 devices is as follows:
      • Node status and performance polling:

    »ABC: performed by Poller 1

    »DEF:performed by Main poller

    »GH: performed by Poller 2

      • Config management

    »ABC: performed by Poller 1

    »DEF: performed by NCM server

    »GH: performed by Poller 2


    NCM 7.x cannot be co-hosted with scalability engines


    •   NCM 7.0 cannot be installed on the same server as a scalability engine: Additional Polling Engine or Additional Web Server





    NCM – Multiple NPM


    • This NCM 6.x/NPM 10.1.x configuration (one NCM integrated to multiple NPMs), is not supported anymore with NCM 7.x/NPM 10.2




    • EOC can offer views integrated between one NCM and multiple NPMs


    EOC displays aggregated data and allows for drill-down to respective UI’s in order to get detailed views.





    Other non-supported deployments


    •   2 NCMs integrated to one NPM, sharing the same NCM DB and Core DB




    •   2 NCMs integrated to one NPM, sharing the same Core DB



    The new set of NCM features, described What we are working on now: NCM a while back, will soon be available for beta.

    If you are an NCM customer with active maintenance, I encourage you to sign-up here for the upcoming Release Candidate.

    Signing-up is a short and easy process that will take you through a few questions about your environment.

    As illustrated by the screenshots below, NCM 7.0 has exciting new capabilities such as the Change Request Approval feature but also new web-based node and account management screens and a tighter integration with Orion Core.

    We hope to see many of you sign-up for this beta and are looking forward to reading your feedback, which is essential to preserve and improve NCM’s quality and usability.

    • Change approval request (one user submits the change request for approval by another user)

    I have created a list of future Change Request Approval improvements that you can vote for Vote for the future improvements of NCM's Change Request Approval feature 

    • The requester view


    • The approver view


    • New web-based network discovery wizard


    • Import devices from Core


    • Keep Orion Core and NCM node list in sync


    • User management (NCM roles integrated to Orion Core’s account management, Active Directory integration)


    • New user controls for Compliance report outcome (sortable node list and advanced controls on column/rules display)


    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.