"Splitting" NPM in to departments

Hello Thwackers,

I've been given a task to separate our NPM installation in to essentially three installations. I am not sure if this is possible, or where to start looking.

Currently, we have 1 large solarwinds installation, consisting of over 500 nodes / 1800 interfaces.

We have mixed in our NPM, Network Core devices, Customer Premise equipment, and items that we have under a monitoring contract.

What we'd like to achieve is we have 3 separate web interfaces, on 3 separate host records ( a records ).

Something like noc.domain.local, support.domain.local and managed.domain.local .

When you hit one of those host records ( which can be same server, different vhost ) you will only be able to log in as certain users, and see only certain devices.

For example, noc.domain.local would allow you to see only devices added in to the NOC NPM instance, and only members of the NOC would be able to log in.

If this is even possible, it'd also be nice to use the same SQL server for all instances.

And to complicate it one further, if possible again, members of noc.domain.local should be able to log in to all three areas, support.domain.local should be able to log in to support and managed, and managed.domain.local should be able to log in to managed only.

We are fairly conformable with SQL commands, and how NPM functions and operates, so even if its just a pointer to something that is similar to this would be a great starting point.

The very last resort for us would be three separate installations, with separate sql servers, and separate credential stores on six separate virtual machines.

Thank you,
Allan Button

Find more posts tagged with

departments

seperation

npm

advanced

Accepted answers

All comments

byrona

Just out of curiosity, is there some reason you want different people logging into different websites for Orion? If it's just for the sake of limiting people to only see specific systems/views, you can do this in Orion via the use of Custom Properties and Account/Views Limitations.

You can purchase licenses for additional web servers from SolarWinds which will allow you to run separate Orion web servers; however, this doesn't specifically allow you to restrict what people can see when they log in, that is down via the method I mention above.

The only real gain you would achieve by breaking Orion out into different installations would be distributing the load but it sounds like that isn't a problem for you.

Allan_Button

Hey Byrona,

I think the end goal is ease of management. When the support team logs in to their instance, and adds a device, it will be listed as their device and will not be visible in the other views.

We already have this working by changing the SQL statement for each of the objects we display, to only show where "department" = "noc" for example.

But when NOC adds a device, if its not categorized, it will show for everyone, or no one.

We feel it would be simpler to separate items such as reports, alerts, and other items if each department had their own instance.

The other reason, is we want members of a department to be an administrator, but restrict access to manage any other departments devices.

When support staff is doing maintenance on a particular service, and they search for all items in that service group, it will show items that are listed in all departments. It'd be preferable if members of support staff could not manage items that belong to NOC, as an example.

If there is another way to handle this, a little easier, it'd love to hear it.

aLTeReGo

As you've described your implementation you would need three separate Orion instances, each with its own database. You could then leverage the Enterprise Operations Console if you needed a centralized console view into all the Orion instances.

What Byrona suggested is what many of our customers do instead. That is, define custom properties to associate nodes with individual departments. Then you use the account limitations tied to those custom properties to restrict views to only devices each department is allowed to see. This would only require a single webserver and a single database, but as each user logs into the Orion web interface they'd be presented with only the nodes/interfaces/volumes/etc. that they've been granted permission to see through the custom properties and account limitations defined.

When adding a node as you described above you are given the option of defining the custom property for that node, which will in turn determine who ultimately has access to the node.

So there's two options for how to go about it. I recommend you weigh the pros-cons associated with each to determine which solution best suites your end goals.

FormerMember

Hi Allan - I am wondering if you are still around and how the story ended. I may be facing a similar task but for somewhat different reasons. Did you end up splitting into separate instances? If so, how. Did you use account limitation to accomplish the task? If so, what were the lessons learned? Thanks

gregatkins

I would recommend as previously suggested and try the account/view limitations to see if it meets your needs. You can apply limitations to more than page views.

rjnicholson

Creating separate Login ID's and then creating separate views that are filtered with Account/View Limitations would be the easiest and most cost effective way for you to achieve this. This is exactly what I have done for several ISP's that use Orion to monitor Network gear and End Points at the Customer Prem. We then create customer login accounts and limit them to what views they have and what they can search/view.

Watch your user load as you may need to push a secondary webfront end for Orion if you have to many users hitting the same box.

FormerMember

My challenge with this is that (at least in my version) dynamic view limitation does not work. I have thousands of nodes. To go through and click which one belongs to which customer is just not feasible (either for me to do or "the system" to maintain). I have set up the customer intformation in the Department field but as I said the dynamic query to set the group membership doesn't work. Thanks for your input though!

rjnicholson

Use Custom Properties in the Editor on the main server. This will soon be integrated into the web console in a coming release, but for now you can use the stand alone Custom Property Editor. Add Custom Properties for the different groups and then populate the value for the nodes. Once done use this to filter. Way more control and has never failed me. Love Love Love my custom properties.