7 thoughts on “RTC vs Cs Groups in Skype for Business (and some issues)

  1. wow, thanks for the article, this is exactly what I’m looking for.
    we are having a problem, where we getting SQL errors logged reporting helpdesk Admins are getting denied on xds database. ONLY when they open skype control panel on a management server where administration tool is installed.
    If they open from a browser from their own computer, error doesn’t get logged.
    So this is because they are only csuseradministrators.
    looking from your article, if we want to make that problem go away, we would have to give them RDP access to all FE servers?
    or can we just add them to rtcuniversaluseradmins group?
    Also, which RTC group we can add people so they can only manage setting up commonareaphones remotly?
    we try to give them as limited access as possible.
    Thanks for your help.


    1. Hey Roger, glad it was helpful.

      I actually can’t explain the behavior you described. When you launch the control panel, it is going to your internal web services and then going to the SE server or being load balanced between your front ends to hit the management web service. That means the control panel is never really local, it’s always remote and will always respect the restrictions of the RBAC roles (the Cs* groups). This means you should have the same experience regardless of where you are connecting to the control panel from.

      I would be curious to see exactly where in the control panel you are seeing that error.

      As for common area phones, that gets a bit tricky. The CsUserAdministrator role is sufficient for managing common area phones, but this must be done using the special remote Powershell session I showed in the article (using the connectionURI). If you don’t want to be limited by that limited Powershell session, you can grant them RTCUniversalUserAdmins membership so that they can connect to a front end via remote Powershell or RDP into the server for the Powershell session.

      Keep in mind, depending on how locked down your AD is and where the common area phone OU is located, you may need to change permissions on the OU. You can do that with the Grant-CsOUPermission cmdlet and you would use ‘Device’ as the object type (CAPs are Contacts in AD, not Device objects, so this is confusing).

      So in my case, I had to run the command: Grant-CsOUPermission -OU “OU=Common Area Phones,OU=mhickok,DC=mhickok,DC=me” -ObjectType Device

      With that command run, any of your CsUserAdministrator members will be able to manage and add CAPs using connectionURI method as long as that is the OU where the phones will reside. If they need to add or manage phones in a different OU you would need to run that same command against the other OU.



  2. Thank you for the very well laid out article. In our SfB2015 installation we just started getting the xds errors for accounts that are members of both CS and RTC groups. One of the account that is getting the errors is the account used to install our SfB installation. I can start a PS session and log into the control panel however once there i can see any users or run commands like get-csuser. Nothing has change in our setup that I am aware of so I dont understand why the error showed up. I will check the SQL server permissions next. Any ideas?


Leave a Reply to Phill Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s