Removes an existing Role-Based Access Control (RBAC). RBAC roles are used to specify the management tasks that users are allowed to carry out, and to determine the scope where users will be allowed to perform these tasks.
Syntax
Remove-CsAdminRole -Identity <String> [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-LocalStore <SwitchParameter>] [-WhatIf [<SwitchParameter>]] |
Remove-CsAdminRole -Sid <String> [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-LocalStore <SwitchParameter>] [-WhatIf [<SwitchParameter>]] |
Remove-CsAdminRole [-Confirm [<SwitchParameter>]] [-Filter <String>] [-Force <SwitchParameter>] [-LocalStore <SwitchParameter>] [-WhatIf [<SwitchParameter>]] |
Parameters
Parameter | Required | Type | Description |
---|---|---|---|
Identity |
Optional |
String |
Unique identifier for the RBAC role to be deleted. The Identity for an RBAC role must be the same as the SamAccountName for the Active Directory universal security group associated with that role. For example, the Help Desk role has an Identity equal to CsHelpDesk; CsHelpDesk is also the SamAccountName of the Active Directory security group associated with that role. |
Sid |
Optional |
Security Identifier |
Enables you to use a Security Identifier (SID) to specify the RBAC role to be deleted. SIDs, which are assigned by Microsoft Communications Server at the time that the RBAC role is created, look something like this: S-1-5-21-1573807623-1597889489-1765977225-1145. The SID for a given RBAC role can be retrieved by using the Get-CsAdminRole cmdlet. |
Filter |
Optional |
String |
Enables you to use wildcards in order to specify the custom RBAC roles to be removed. For example, to remove all the custom roles that include the string value "Redmond" in their Identity you can use this syntax: -Filter "*Redmond*". |
Force |
Optional |
Switch Parameter |
Suppresses the display of any non-fatal error message that might arise when running the command. |
LocalStore |
Optional |
Switch Parameter |
|
WhatIf |
Optional |
Switch Parameter |
Describes what would happen if you executed the command without actually executing the command. |
Confirm |
Optional |
Switch Parameter |
Prompts you for confirmation before executing the command. |
Detailed Description
Role-Based Access control (RBAC) enables administrators to delegate control of specific management tasks in Microsoft Communications Server. For example, instead of granting help desk and support personnel full administrator privileges, you can give these employees very specific rights: the right to manage user accounts, and only user accounts; the right to manage Enterprise Voice components, and only Enterprise Voice components; the right to manage archiving and Archiving Server, and only archiving and Archiving Server. In addition, these rights can be limited in scope: someone can be given the right to manage Enterprise Voice, but only in the Redmond site; someone else can be given the right to manage users, but only if those user accounts are in the Finance OU.
The Microsoft Communications Server implementation of RBAC is based on two key elements: Active Directory security groups and Windows PowerShell cmdlets. When you install Microsoft Communications Server, a number of universal security groups - CsAdministrator, CsArchivingAdministrator, CsHelpDesk, etc. - are created for you. These universal security groups have a one-to-one correspondence with RBAC roles; that means that any user who is in the CsArchivingAdministrator security group has all the rights granted to the CsArchivingAdministrator RBAC role. In turn, the rights granted to an RBAC role are based on the cmdlets assigned to that role (cmdlets can be assigned to multiple RBAC roles). For example, the CsArchivingAdministrator role has been assigned the following cmdlets:
Get-ArchivingPolicy
Grant-ArchivingPolicy
New-ArchivingPolicy
Remove-ArchivingPolicy
Set-ArchivingPolicy
Get-ArchivingConfiguration
New-ArchivingConfiguration
Remove-ArchivingConfiguration
Set-ArchivingConfiguration
Get-CsUser
Export-CsArchivingData
Get-CsComputer
Get-CsPool
Get-CsService
Get-CsSite
The preceding list represents the only cmdlets that an Archiving Administrator is allowed to run. If he or she tries to run, say, the Disable-CsUser cmdlet, that command will fail; that’s because Archiving Administrators do not have the right to run Disable-CsUser. This applies to the Communications Server Control Panel as well. An Archiving Administrator cannot disable a user by using the Control Panel simply because the Control Panel is aware of, and abides by, RBAC roles. (Any time you run a command in Control Panel you are actually calling a PowerShell cmdlet. If you are not allowed to run Disable-CsUser it won’t matter whether you directly run that cmdlet from Windows PowerShell or if you indirectly run the cmdlet from within the Communications Server Control Panel: the command will fail.)
Note that RBAC applies only to remote management. If you are logged on to a computer running Microsoft Communications Server and you open the Communications Server Management Shell RBAC roles will not be enforced.
When you install Microsoft Communications Server the setup program creates a dozen or so built-in RBAC roles, roles that cover such common administrative areas such as voice administration, user management, Response Group administration, and so on. These built-in roles cannot be modified in any way: you cannot add or remove cmdlets to the roles and you cannot delete these roles. (Any attempt to delete a built-in role will result in an error message.) However, you can use the built-in roles to create custom RBAC roles. These custom roles can then be modified by changing the administrative scopes; for example, you could limit the role to managing user accounts with a particular Active Directory OU.
Any custom roles you create can be deleted by using the Remove-CsAdminRole cmdlet. Note that Remove-CsAdminRole will not delete the Active Directory security group that corresponds to the custom role, nor will it remove any of the members who have been assigned to the group. Instead, the cmdlet simply ensures that this custom role can no be used to delegate control of Microsoft Communications Server.
When you delete an RBAC role PowerShell will respond by asking if you are sure you want to delete this role; if you do not respond to this prompt(or do not respond by saying Yes) then the role will not be deleted. To avoid these confirmation prompts, you can change the value of the automatic variable $ConfirmPreference. For more information, type the following at the Windows PowerShell prompt and then press ENTER:
Get-Help about_automatic_variables | more
Return Types
Remove-CsAdminRole deletes existing instances of the Microsoft.Rtc.Management.WriteableConfig.Settings.Roles.Role object.
Examples
-------------------------- Example 1 ------------------------
![]() |
|
---|---|
Remove-CsAdminRole -Identity "RedmondHelpDesk" |
The command shown in Example 1 deletes the RBAC role with the Identity RedmondHelpDesk.
-------------------------- Example 2 ------------------------
![]() |
|
---|---|
Remove-CsAdminRole -Filter "*Redmond*" |
The preceding command deletes all the RBAC roles that have the string value "Redmond" somewhere in their Identity.
-------------------------- Example 3 ------------------------
![]() |
|
---|---|
Get-CsAdminRole | Where-Object {$_.IsStandardRole -eq $False} | Remove-CsAdminRole |
In Example 3, the command deletes all the custom RBAC roles that have been created for use in your organization. To do this, the command first calls get-CsAdminRole without any parameters; that returns a collection of your RBAC roles. This collection is then piped to the Where-Object cmdlet, which selects only those roles where the IsStandardRole property is equal to (-eq) False ($False): by default, any role meeting that criterion is a custom role. In turn, those custom roles are then piped to, and deleted by, the Remove-CsAdminRole cmdlet.