There is a lot of confusion surrounding Nimsoft’s User Administration and Account Administration, in an effort to bring everyone onto the same page I’ve written up the following breakdown of the two components and explained when they should, and shouldn’t be used.
User Accounts are associated to ACL’s and is where users go to setup segregation within the Nimsoft Windows Clients like the Infrastructure Manager and Service Level Manager to lock users/groups out of specific areas, this may be setup very granular, note that the fields do support both pattern matching and regex too.
User Accounts created within User Administration can be used to log into the Unified Monitoring Portal and this is the recommended area to add user accounts for enterprises when data segregation in the UMP isn’t a concern, however, when working with an enterprise or service provider where they need to restrict data and alarms from specific users, then you’ll need to use Account Administration.
This is what’s used to setup users and accounts for the Nimsoft Unified Monitoring Portal and is completely separate from the user accounts created within the Infrastructure Manager, however, do not create User Names in Account Administration using the same names as you’ll run into several issues related to consistency and confusion.
The New Account screen is what you’ll use to setup accounts, for Service Provider’s you would add an account using the (monitored) customers name, for an enterprise you would name a new account using the group responsible for the nodes you’re associating them too like ‘Exchange Group’. After creating a new account, you’ll select the hub/origin you want to associate them to, and then you’ll need to create new users under the Contacts section.
Multi-tenancy with a Single Hub
Using Nimsoft today, if an account like an MSP wants to use a single hub to monitor multiple customers, you’ll need to modify the origin at the Controller level – the hub name the robot is connected too is automatically used as the robots origin by default. To overwrite the origin, open the Controller Probe and go to the Advanced tab and supply it with a new origin.
The Robot will need to be restarted if you add the origin to it using the 'overwrite' option, also, those of you looking to push this out in bulk using a custom CFG, the change (even though it’s made using the Controller) is not written to the controller/Robot.CFG, instead it's written to the Spooler CFG:
origin = MyOrigin
Ideally you would have made the changes listed above before deploying any probes to the target server, however, if you already had probes on your robots where you’ve overwritten the origin, you’ll need to modify the Nimsoft database to update the (previously) collected QoS objects. To modify this you can do the following:
- Open the Nimsoft Service Level Manager
- Open the Database Status screen from the Tools menu
- From the Active Objects tab, select the nodes you wish to modify, right click on them and select ‘Change Origin’
By doing the above, all you’ve done is modify the origin field in the S_QOS_Data table, so if you have a massive amount of objects you need to change, it’ll likely be easier to just write a quick SQL query to do the heavy lifting for you.
Once the aforementioned steps have been completed you’ll be able to see the new origins listed under the Ownership section in the New Account Window.
Multi-Tenancy: A Single Robot for Multiple Customers
Another situation we’ve run into a number of times is when a service provider has multiple customer devices they’re monitoring from a single robot, for example; one Interface Traffic Probe but several customer devices.
To work through this issue you’ll need to leverage the CMDB Lookup Probe, this is a field developed solution you’ll not find in the archive so get it on the forums here.
The attached doc is 100% what's written out here, however it includes screenshots.
Hope this helps!