Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 7

Adding Nodes that can only be viewed by the group that entered them

Not sure if the title is correct so hope this clears up the questions.  We have been using NPN for a few years and have several nodes entered.  We now have other divisions that want to start to add there nodes into NPM.  What we want to do is allow the division to add there node but only they will see what nodes they have entered and not see the nodes others have added.  I can not find anything in Solarwinds documentation or here on THWACK.  Is there anyway this is possible?


0 Kudos
4 Replies

There are a lot of ways to do this.  In all cases you would want to apply account limitations to filter them to only see nodes that are intended for their consumption.  The specifics of how you set up that limitation are up to your organization.  You could set them up based on dynamic queries in groups, aka if the node names would have some way of indicating what division they belong to, or maybe specific ip blocks.  Another way is to set up a custom property to tag the nodes by whatever division they are in, but the danger in relying on a custom property that you have to set manually is that if someone forgets to set it or sets the value incorrectly then that node would effectively disappear from them and they wouldn't be able to correct it without help from someone who is not under the same limitation.  Ideally you want to come up with a way of differentiating the nodes that does not require anyone to manually do anything.

- Marc Netterfield, Github
0 Kudos

Thank you. That is a great list of solutions. The one thing that will happen before this is the node needs to be added. I’m not to keen on giving everyone right to manage nodes before the group step. Or can I just set the group limitation and give them node management rights and they can only add or delete there nodes from the group?

0 Kudos

The latter, if you give them management they can manage any nodes they can see, but with the account limitation they will only see nodes that match the criteria you set up on their account.

- Marc Netterfield, Github
0 Kudos


In short yes you can, and that's exactly what we did.  There was a department in our organization that had a fairly small IT department with a small budget.  We offered to manage their equipment in Solarwinds as a service to them. This is what I did to achive what your taking about.

  1. Created dynamic group that looked for that "key" custom property in a node.
  2. Added a "key" custom property comment in that group.
  3. Created the user group with the limitations of the "key" node custom property and the "key" group custom property. 
  4. The user group was given managed node rights.  This allowed them the ability to add and remove nodes but limit their views to the nodes with the "key" custom properties. 
  5. Alarms were built that look for the "key" custom properties as the scope of the alert.

However, there are some caveats to be aware of.

  1. When they add a node to NPM they have to enter the "key" node custom property before finalizing the installation.  If they forget then they loose visibility to the node and of course NPM will not alert on the node when it goes down. If you go down this road I would highly suggest writing up some sort of documentation and clearly addressing that issue.  I would then suggest you offer your (team) services in fixing the "key" custom properties.
  2. This solution works great when doing a single node discovery.  It doesn't work, or I haven't figured it out, when doing a mass network discovery.
  3. Alerts and Events - I know NPM has the way to limit the alerts and events so that this team will only see alerts and events that relate to them, I just haven't spent enough time on it to figure it out and it hasn't been a high enough of an issue to push it to the front of my work load.  This being said this user group will see all alerts and events in NPM.  If this is an issue I would suggest spending time on figuring this one out once everything is implemented.
  4. User views. - I would also suggest giving this new group their own view and then giving them the ability to modify views.  That way this group and change the views to better fit their needs and not affect other users in NPM.  It makes it feel more personal to the different teams.
  5. Company Solarwinds users DL - If you haven't done so already I would also suggest making an email DL of your Solarwinds Users that way you can send out one email to the different teams to let them know when you're going to do maintenance.

The beauty of it all, I've added multiple user groups and they all have limitations on what they see, with the exception of alerts and events.  They all have a feeling of ownership of Solarwinds and they can do what they need to do with out pulling me away from doing what I need to do.

0 Kudos