Unless the service experiences a complete power/hardware failure where it instantly shuts down, usually there are indicators that a service may be experiencing health issues. Operations Manager looks to populate those indicators in the console to give operators an opportunity to proactively schedule maintenance, and/or plan a remediation strategy for the ailing server/service.
This is where OpsMgr’s user roles comes into play, by delegating out only portions of the console that are relevant to that respective operations team, they can monitor and view the health of their service and take a more proactive approach. By doing this, unexpected outages should be reduced, which would better serve the business, and make for a happier end customer.
Operations Manager provides five built-in user roles. The product does not allow new user roles to be defined, so what you see is what you get. Each user roles comes defined with a group assigned to it, but an organization can leverage the existing roles to delegate the console out to operators with different levels of permission. The roles and a brief description are provided in the table below.
To actually delegate console access, Operations Manager provides a wizard based role definition, that makes it easier for Administrators to caonfigure views, tasks and group definitions. Additionally, different groups can belong to different delegation profiles. For example, my SQL Admins group will be delegated full Operator access to the SQL Management Pack and read only access to the Windows Operating System Management pack.
You can go through the same steps above to create a Read-Only Operator Role for our SQL Admins team example. The only exception is that on the “Approve Groups” wizard window, I only choose to target the “SQL Computers” group because I am targeting the Windows O/S management pack.
The investment you do into this console delegation will pay off in the next step of configuring alerts for different groups.