Test admin topology rights in Lync Server 2013

Lync Server 2013

Letztes Änderungsdatum des Themas: 2016-12-08


Verification schedule

After initial Lync Server deployment. As needed if permission-related issues arise.

Testing tool

Windows PowerShell

Permissions required

When run locally using the Lync Server-Verwaltungsshell, users must be members of the RTCUniversalServerAdmins security group.

When run using a remote instance of Windows PowerShell, users must be assigned an RBAC role that has permission to run the Test-CsSetupPermission cmdlet. To see a list of all RBAC roles that can use this cmdlet, run the following command from the Windows PowerShell prompt:

Get-CsAdminRole | Where-Object {$_.Cmdlets -match "Test-CsSetupPermission"}

By default, only domain administrators can enable a Lync Server topology and make large changes to the Lync Server infrastructure. This won't be a problem as long as your domain administrators and your Lync Server administrators are one and the same.In many organizations Lync Server administrators do not hold administrative rights to the whole domain. By default, that means that these administrators (defined as members of the RTCUniversalServerAdmins group) can't make Lync Server topology changes. To give members of the RTCUniversalServerAdmins group the right to make topology changes, you must assign the required Active Directory permissions by using the Grant-CsSetupPermission cmdlet.

The Test-CsSetupPermission cmdlet verifies that the required permissions that are needed to install Lync Server or one of its components are configured on the specified Active Directory container. If the permissions are not assigned, you can then run the Grant-CsSetupPermission cmdlet to give members of the RTCUniversalServerAdmins group the right to install and enable Lync Server.

For a detailed list of permissions assigned by Grant-CsSetupPermission, see the blog post Grant-CsSetupPermission and Grant-CsOUPermission.

To determine whether setup permissions are assigned for an Active Directory container, call the Test-CsSetupPermission cmdlet. Specify the distinguished name of the container to be checked. For example, this command verifies setup permissions on the container ou=CsServers,dc=litwareinc,dc=com:

Test-CsSetupPermission -ComputerOU "ou=CsServers,dc=litwareinc,dc=com"

For more information, see the help topic for the Test-CsSetupPermission cmdlet.

If Test-CsSetupPermission determines that the required permissions have already been set on an Active Directory container then the cmdlet will return the value True:


If permissions are not set, Test-CsSetupPermission will return the value False. Note that this value will typically be enclosed in many warning messages. For example:

WARNING: Access control entry (ACE) atl-cs-001\RTCUniversalServerAdmins; Allow; ExtendedRight; None; None; 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2

WARNING: The access control entries (ACEs) on the object "CN=Computers,DC=litwareinc,DC=com" are not ready.


WARNING: "Test-CsSetupPermission" processing has completed with warnings. "2" warnings were recorded during this run.

WARNING: Detailed results can be found at "C:\Users\Admin\AppData\Local\Temp\Test-CsSetupPermission-1da99ba6-abe2-45e4-8b16-dfd244763118.html".

Although there are rare exceptions, if Test-CsSetupPermission fails that typically means that setup permissions are not assigned for the specified Active Directory container. Those permissions can be assigned by using the Grant-CsSetupPermission cmdlet. For example, this command grants setup permissions to the Computers container in the domain litwareinc.com:

Grant-CsSetupPermission -ComputerOU "cn=Computers,dc=litwareinc,dc=com"

For more information, see the help topic for the Test-CsSetupPermission cmdlet.