Issue:
So you want to have some people have access to see details in the SCOM console but you don’t trust them after having a conversation that goes something like this:
Now, listen. I’ve got a JOB for you. See this button? DON’T TOUCH IT!
So… what’ll happen?
That’s just IT! You don’t KNOW! Maayyyybeeee something bad?… Mayyyybeeee something good! I guess we’ll never know! ‘Cause you’re not going to touch it! You won’t TOUCH it, will you?
Solution:
Actually this is quite simple and very effective.
Administration Tab: User Roles
SCOM 2007 R2 comes with built in roles, you may have seen them Administration, Security, User Roles. Whats that you say? You can’t use these because the users you want to grant access should only get specific server like SQL only and there give access to everything? Well not to worry I’ll get to that in a minute.
Default Roles
| Profile type | Profile description | Role scope |
|---|---|---|
Administrator | Has full privileges to Operations Manager; no scoping of the Administrator profile is supported. | Full access to all Operations Manager data, services, administrative, and authoring tools. |
Advanced Operator | Has limited change access to Operations Manager configuration; ability to create overrides to rules; monitors for targets or groups of targets within the configured scope. Advanced Operator also inherits Operator privileges. | Can be scoped against any groups, views, and tasks currently present and those imported in the future. |
Author | Has ability to create, edit, and delete tasks, rules, monitors, and views within configured scope. Author also inherits Advanced Operator privileges. | Can be scoped against any target, groups, views, and tasks currently present and those imported in the future. The Author role is unique in that this is the only profile type that can be scoped against the targets. |
Operator | Has ability to edit or delete alerts, run tasks, and access views according to configured scope. Operator also inherits Read-Only Operator privileges. | Can be scoped against any groups, views, and tasks currently present and those imported in the future. |
Read-Only Operator | Has ability to view alerts and access views according to configured scope. | Can be scoped against any groups and views currently present and those imported in the future. |
Report Operator | Has ability to view reports according to configured scope. | Globally scoped. |
Report Security Administrator | Enables integration of SQL Reporting Services security with Operations Manager roles. | No scope. |
Pick a type that has the level of access you are looking for and then right click on Users Roles and create a new role.
General Properties : Here you can give your role a name, description and add members to it. Personally I suggest adding AD groups and not individual users but hey, it’s your environment so your call.
Group Scope : This is the half the magic but I talked about earlier. Here you define what groups of objects you want the user to be able to affect.
Tasks: You can approve all or only specific tasks you want this rile to be able to run.
Views: The second half of the magic. Here you can pick specific branches of your monitoring tree and that’s all this rile will be able to see.
Now your console may look something like this for a UPS operator…
All right now, wasn’t that fun? Let’s try something else…..
I’ve found that editing the views tab does not remove views from the admins monitoring tab nor affect permissions – is there a second part to isolating out what will display?
If you are trying to limit what non-administrator users can see you should create a new role,
set the Group Scope, and then edit the views tab.
Aside from that make sure the users in question are only a member of the groups you want. If they are also in one of the default roles they will still have access to other areas.
I created new role I set the Group Scope, and then edit the views tab.
Still showing everyting for my Read only user. and alos It is not a member of any other group.
Is there other work around on this?
Sorry to hear it is not working for you.
If you created a new role, defined the scope and the views then normally it works.
The first thing I would check is if this user is receiving access via another group that it is a member of, like the local admins group on the server or something like that.