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.