By now, you have probably taken the first few steps toward using Operations Bridge and/or evolving your Operations Manager (OM) installation to Operations Manager i (OMi). If yes, have you noticed that setting the user permissions for operators/admins in OMi is different compared to OM? IF not, you might be new to this journey and might be wondering how to set up equivalent permissions for your operators in OMi. If this is indeed the case, then continue reading to get some answers to your likely questions around this topic. The blog “HPOM Users: Here is why and how to move to OMi” makes a good reading to get started on the evolution journey.
Permissions in OMU/L/W
In Operations Manager, operators are assigned permissions through Roles (in OMW) or Profiles (in OMU/L) which in turn are assigned to the operators. The most important permissions are given on the basis of Node groups and message groups. Node group assignment allows users to see and work upon events coming from the specific nodes in the assigned groups. Message groups assignment allows them to access events with the assigned message group AND coming from the assigned nodes. A combination of node groups and message groups assigned to a role, defines the responsibility matrix of that role.
Figure 1: Event Responsibilities in OM
Permissions in OMi:
In OMi versions 9.x, although the concept of user role existed, only some out-of-the-box user roles were available—and newer roles could not be created. Permissions had to be setup at the user group level or at the individual user level in BSM/OMi 9.x. User Roles have been introduced starting with OMi10—easing this process. Now, we must define different user roles and assign detailed permissions to these roles which are in turn assigned to users and user groups.
Setting up OM Node group equivalent permissions in OMi:
In OMi, we work with CIs and CI-centric monitoring configuration, unlike the node and node-group centric approach in OM. The node groups in OM are represented as CI Collection type of CIs in OMi and access to the CIs is provided using RTSM views. If you want to have exact same node group based permissions in OMi, then follow these steps:
- Create views corresponding to each node group that has been synced into OMi as CI Collection or that have been created by other means
- Assign the relevant views corresponding to each node group that you want to provide permissions for, to the appropriate role
OM message group equivalent permissions in OMi:
Message group in OM event is called event category in OMi. For message group permissions, define:
- Event category, if needed
- Assign permissions to event categories for each role
NOTE: please note that in OMi, detailed permissions are assigned based on “events assigned to a user” and “events not assigned to a user” type of events. Event category-based permissions are applicable for the “events not assigned to a user” kind of events.
Other permissions in OMi:
Tools: Tools in OMi are linked to CI types and tools categories. In order to run tools, the operator’s role should have permissions to the appropriate tool categories. (This works in a similar manner in OM as well.)
Unlike in OM, there are many more resources that can be assigned to users in OMi and hence more permissions should be assigned :
Workspace pages: For operators to have access to the central feaures of OMi, assign predefined pages like Event Perspective, Health Perspestive and Performance Perspective. Of course, there are other pre-defined pages that can be assigned to the roles. You can also create a custom “my workspace” page for each role that includes dfferent UI components of the OMi application. For example, a page that includes an event dashboard, events console, available actions and KPI over time components.
Admin tasks: In OMi, there is no difference between admin and operator users and we can assign a mix of permissions including admin UIs and operator UIs. For example, a user could be given permission to create and deploy new policies/aspects, create new event dashboards and also view the events and work on the events.
An example of a configuration workflow to create a user with restricted access to certain node group and message group events in OMi:
- Create a view for node group called “oracle” that includes some node CIs running oracle server
- Create a role called “oracle-users” and assign the permissions to the newly created view and event category called “oracle” ( create it, if needed)
- Assign some more permissions like workspace pages of event perspective and health perspective
Figure 2: RTSM View for oracle CI collection
Figure 3: View assignment to the role
Figure 4: Event category (message group) assignment to the role
Figure 5: Final role definition
If you would like to go into more details about this topic, please refer to the Operations Bridge Evolution Guide , and read the chapter “Prepare Operator Console”.
Learn more about Operations Manager and Operations Manager i here.
You can also download trials of the software to experience them for yourself.
Learn more about Operations Manager i at the product page here.
The OM-to-Opsbridge evolution program including license exchange details is now live. Search on the tag OM2OpsBridge to find blogs discussing this program and evolution to OpsBridge.