• Glen (Xapity)

Part 1: Service Manager (SCSM) Security User Roles


Service Manger Security User Roles allow administrators to build up quite complex security permissions for analysts. They are cumulative and an analyst can be a member of multiple roles. This can make trouble shooting permissions quite difficult and I have written a script available of Technet Gallery to help report on security permissions.


Part one of this series gives a general background on User Roles and security in Service Manager and then Part Two covers the PowerShell script that can help with troubleshooting and reporting.

Also refer to Part 2: SCSM Security User Roles Script

Roles versus Profiles

It is a little confusing when talking about security in Service Manager because we have User Roles and User Role Profiles (which I will call User Profiles). The User Roles are what you see in in the Admin\Security area of the console and are what you can add users and groups to. User Profiles are the "templates" that you can use to create a new custom User Role and provide base functionality that you cannot edit or change. Unfortunately it is very easy to user the terms interchangeably and even the official Microsoft documentation will do this occasionally.

The confusion starts because the default out of the box User Role names match the system User Profiles:


The only difference in the name is the "s" on the end of the User Role.

It is not possible to create your own custom User Profiles. These are system defined and cannot be edited or changed.

User Roles

The out of the box User Roles cannot be customised and generally do not allow fine grained control of service manager. They use the "All Settings" for most things and this is where you want more control ie they give All views access, where you need to give only a selection of views to the analyst. As a result it is better to create custom User Roles based on the out of the box User Profiles.

It can be difficult to build up the exact permission set you need based on the User Profiles (which cannot be customized). For example you want to give the analyst the ability to edit Config Items and this is not available in the Incident Resolver Profile, but it is available in the Advanced Operator Profile. It would be possible to create two User Profiles - one based on Incident Resolver an one on Advanced Operator and put the analyst in both User Roles. But then the analyst would be able to do other actions eg edit Release Records which you do not want analysts working on the Help Desk to be able to do.

There is no easy solution to this, either the analyst has more permissions and can do the task required or the can't. You could look at creating a new custom task that allows the function you need, in this example, the editing of the CI, but this is a lot of work and so a lot of organizations just comprise on giving the analyst higher permissions.

Appendix A - List of User Role Profiles

To make the best decision in a case like this you need to know exactly what permissions the User Profile is giving the analyst. The SCSM 2012 documentation has more detail on the user profiles Appendix A - List of User Role Profiles in System Center 2012 - Service Manager and it is still relevant to SCSM 2016. Pay particular attention to the Instance Scope column in the table - it is important to know just where the permission can be used.

Some of the more basic actions where defined in the Service Manager 2016 documentation and are included here:










Default Security User Roles

I do not recommend using the existing default security user roles. You can only add users to the role and cannot actually change\control any of the other settings. Always create a new custom User Role based on the equivalent User Profile. The default User Roles will give access to All objects (eg All Tasks, All Views, All Queues etc), a very easy way to give access to too many things in Service Manager. Not the End User out of the box role will give too many permissions to users and should also be customised as required.

List of Default Security User Roles

  • Activity Implementers

  • Administrators

  • Advanced Operators

  • Change Initiators

  • End Users

  • Read-Only Operators

  • Authors

  • Problem Analysts

  • Workflows

  • Incident Resolvers

  • Change Managers

  • Report Users

  • Release Managers

  • Service Request Analysts

RBAC Security Roles

This post, Implementing RBAC in System Center 2012 R2 Service Manager from Kenneth van Surksum gives more information on and provides good advice that is still relevant to Service Manager 2016.

User Roles are Cumulative

As User Roles are cumulative it is quite common to build up a hierarchy of permissions. That is, to create a base role that has all the permissions (base profile permissions, some base tasks, templates etc) that ALL analysts need. This is usually done for each work item type eg Base Incident Resolver or Base Change Initiator.

Then a second custom role is used for each support group or team. This may also be built of the same profile (ie incident resolver or change initiator) or I have seen some organisations use a read-only profile. Either way this custom role has the permissions that are specific to the support group or team ie tasks that only they use, views for there support group jobs, queues, templates etc.

This can result in a large number of User Roles, but it does give the fine grained RBAC like user security that many organisations need.

In some organisations they found it simpler to just create one custom role for each Support Group with all the permissions that they needed on that role. No cumulative permissions and what you see is what you get.

There is no wrong or right way, it depends on your business needs and the work practices you have in your organisation.

Clone User Roles

Managing User Roles can be difficult and replicating all those check boxes is difficult. To help with this I would suggest Itnetx Clone User Role which is a free download. It copies an existing custom role within the same instance.

It helps with testing if you need to make changes to a role - clone the role, make the changes and only put testers in the role. This allows you to quickly replicate what the exact permissions for that role.

RBAC Security Roles

This post, Implementing RBAC in System Center 2012 R2 Service Manager from Kenneth van Surksum gives more information on and provides good advice that is still relevant to Service Manager 2016.

Transferring Permissions between Environments

I have always found it annoying that security roles are not stored in a Management Pack that can be exported and then re-imported into a new instance. It is always a manual task to recreate the security user roles in a new instance ie when you have a test, pre-prod and prod instances keeping the security roles aligned is painful.

Hopefully the script will make it easier to document the security permissions and help keep environments consistent for testing purposes.

See next: Part 2: SCSM Security User Roles Script

#Customizations #SCSM2016

© 2020 Xapity PTY LTD ABN: 81 611 883 482

  • White RSS Icon
  • White YouTube Icon
  • White Vimeo Icon
  • Facebook Clean
  • Twitter Clean