It’s all about Lync 2013 RBAC

Update: This article also applies to Skype for Business 2015. The RBAC model is exactly the same as for Lync 2013, only with the exception of some extra cmdlets that are available.

RBAC stands for Role Based Access Control. It can be powerfull and help medium to large companies in dividing permissions accross different people without endangering the stability. However, Lync RBAC administration has a few limitations that have not yet been very clearly documented. Having implemented Lync RBAC in a large Lync 2013 deployment (60+ Lync sites), a lot of these unknown “features” came forward. I’ll start by explaining the principles.

Admin Roles

Lync RBAC is based on admin roles. Each admin role has a set of Lync commandlets (cmdlets). A user in a role is allowed to run the cmdlets assigned to that role. Lync 2013 has a set of default roles, which can be used as is or as template to create new roles.

Lync Default Roles

Here is a list of the Lync default groups:

CSAdministrator, CSVoiceAdministrator, CSUserAdministrator, CSResponseGroupAdministrator, CSLocationAdministrator, CSArchivingAdministrator, CSViewOnlyAdministrator, CSServerAdministrator, CSHelpDesk, CSResponseGroupManager, CsPersistentChatAdministrator

To get an overview of all the cmdlets associated with the default Lync RBAC roles, please see the Excel sheet from Ehlo World.

View an Admin Role

So how can we view the admin roles and what can be configured? To better understand this, we use a default RBAC as example, in this case CSAdministrator. To view the properties, run the following Lync PowerShell cmdlet.

PS C:> Get-CsAdminRole -Identity CSAdministrator
Identity       : CSAdministrator
SID            : S-1-5-21-123456789-123456789-123456789-123456 
IsStandardRole : True 
Cmdlets        : {Name=Get-CsClientPolicy, Name=Set-CsClientPolicy, Name=Remove-CsClientPolicy, Name=New-CsClientPolicy...} 
ScriptModules  : {} 
ConfigScopes   : {Global} 
UserScopes     : {Global} 
Template       :

So what do these settings mean?

  • Identity
    Name of the RBAC admin role.
  • SID
    The Security Identifier of the Active Directory Group.
  • IsStandardRole
    This is set to True if it is a Lync default role. To get an overview of all the default roles, run the following cmdlet: Get-CsAdminRole | ? {$_.IsStandardRole -eq $True}
  • Cmdlets
    A list of all cmdlets associated to the Admin Role. To expand the list of cmdlets: Get-CsAdminRole -Identity CSAdministrator | Select -Expandproperty Cmdlets
  • ConfigScopes
    This is the Lync site (or sites) where the RBAC role applies to. By default it is set to Global, which implies all sites. If sites have been added, this will show the site number (e.g. Site:2)
    Note that Branch Sites also need to be mentioned separately.
  • UserScopes
    Limits the scope of the cmdlet to user management activities within the specified OU. Note that this can ONLY be OU’s, you cannot add the top level domain. This needs to be added with the distinguished name of the OU. Adding an OU, will ensure management over ALL users in that OU, including child-OU’s.
  • Template
    The template that is used to create the Admin Role, empty for default RBAC roles.
    Note that using a template will only copy the specific cmdlets to the new admin role.

How to create new Admin Role?

To create new admin roles, also commonly referrerd to as Custom RBAC roles,  first a new Universal Security Active Directory (AD) group has to be created. After the AD group is created, the Custom RBAC role can be created in Lync. You can add and/or remove cmdlets from the Custom RBAC role and add a user can to the specific role (or better said the AD group). At that point the user is able to use the associated cmdlets.

At least…to some point.

RBAC need-to-knows

So what do you need to know and what are the limitations of using Lync RBAC administration?

Use of Lync Remote PowerShell

The first important fact that you need to know is that RBAC permissions will only be applied when using either Lync Remote PowerShell connections or Lync Control Panel.

A common error when you run the Lync cmdlet after you start Lync Management Shell directly from your Lync Server is the following:

The following SQL Server error occurred: “The EXECUTE permission was denied on the object ‘XdsPublishItems’, database ‘xds’, schema ‘dbo’

To resolve this, make sure you connect via Lync Remote PowerShell to your Lync environment. This Remote Lync connection will import the cmdlets that you’re allowed to run on your local machine (*read “not all cmdlets are part of the Lync RBAC model”).
You do not have to install the Lync Management tools on your local computer for this to work. When using Lync Remote PowerShell, not all cmdlets will be imported to the local computer.

For example: Test-CsDatabase can only be run straight from the Lync Management Shell on a Lync server and not with Lync Remote PowerShell.

Not all cmdlets are part of the Lync RBAC model

Not every cmdlet that is available in Lync is associated with a Lync admin role.

For example, Enable-CsAdDomain is not related to the Lync RBAC model. For this cmdlet, you will need to be Domain Admin to actually execute this and you do not need any Lync specific permissions.

You can verify if a cmdlet is part of the Lync RBAC model, by verifying the cmdlet is associated with one of the default RBAC roles. Run the following cmdlet:

Get-CsAdminRole |  Where {$_.Cmdlets -match "<cmdlet-to-check>"}

If this does not return a default RBAC role, you will need different permissions to execute this cmdlet.


When creating a Custom RBAC role, you’re actually creating an new AD group which has no access to the CMS database. When you execute a cmdlet, a connection to the CMS always takes place to check for the RBAC constraints. Missing access to the CMS will also result in SQL related errors.

To make sure this does not occur, you can add your custom RBAC roles (or actually ofcourse the AD group) as a member of the RTCUniversalReadOnly group. This will make sure the administrators at least have read access to the CMS database.

When using ConfigScopes…

One of the most misunderstood limitations in a Custom RBAC role is when using the ConfigScopes option to limit the administrative access to certain Lync sites. The users in that scoped admin role will have limited ability to create and/or modify certain objects.

The issue when limiting ConfigScopes to something other than the default Global is that users will not be able to create globally unique objects in the CMS database.

To explain this with an example, let’s look at a user-scoped client policy versus a site-scoped client policy. When creating a client policy with the New-CsClientPolicy option, the user-scoped client policy creation will fail, as this is a globally unique entry. This will always fail although the user is added to a custom admin role that has the cmdlet mentioned. The site-scoped policy will work only on the site that the user has permissions for. You will see the following error:

Cannot run the cmdlet because it is outside the user’s role-based access control (RBAC) scope.

This issue also explains a few other strange behaviours that may occur. One other example is when using the Voice Routing Test Case via the Lync Control Panel. When a user tries to run this, the user will not get any information back and the system does not seem to be doing anything. What actually happens in the background, is the system is trying to create a temporary user-scoped policy. As this is outside of the user’s RBAC scope, the system does not return any result.

Greig Sheridan (Lync MVP) also ran into this specific scenario and has created a great script to still be able to test Voice Routing (Test-CallRouting.ps1).


Although Lync RBAC is very usefull, it can become very difficult to manage if you don’t correctly configure the permissions from the beginning.

And as always, keep things simple.

Feel free to add your experience with Lync RBAC below.

Hans Sleurink

Hans Sleurink works as a Consultant at Wortell in the Netherlands where he designs and deploys Unified Communications solutions. His main focus is on, but not limited to, Microsoft Teams (migrations), including Enterprise Voice, contact center solutions, AudioCodes, Direct Routing, Exchange, Office 365, Active Directory and other UC related topics.

More Posts - Website

Follow Me:

Leave a Reply




This site uses Akismet to reduce spam. Learn how your comment data is processed.