[This is preliminary documentation and is subject to change. Blank topics are included as placeholders.]

Creates a new Role-Based Access Control (RBAC) role. RBAC roles are used to define 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

New-CsAdminRole -Identity <String> -Template <String> [-ConfigScopes <PSListModifier>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-InMemory <SwitchParameter>] [-LocalStore <SwitchParameter>] [-UserScopes <PSListModifier>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

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.

Template

Required

String

Name of the built-in RBAC role which will serve as a template for the custom RBAC role being created. All new RBAC roles must be based on an existing role; it is not possible to create a "blank" RBAC role (that is, a role with no cmdlets assigned to it). However, after the custom role has been created you can then use the Set-CsAdminRole cmdlet to modify the properties of the new role.

ConfigScopes

Optional

PS List Modifier

Used to limit the scope of the cmdlet to configuration settings within the specified site or organizational unit. To limit the cmdlet scope to a single site use syntax similar to this: -ConfigScopes site:Redmond. To limit the cmdlet scope to a single organizational unit, use syntax similar to this: -ConfigScopes "OU:ou=Redmond,dc=litwareinc,dc=com". Multiple sites or OUs can be specified by using a comma-separated list: -ConfigScopes "OU:ou=Redmond,dc=litwareinc,dc=com", "OU:ou=Dublin,dc=litwareinc,dc=com".

If no value is specified for this parameter then the role will have a global scope when it comes to configuration settings.

UserScopes

Optional

PS List Modifier

Used to limit the scope of the cmdlet to user management activities within the specified site or organizational unit. To limit the cmdlet scope to a single site use syntax similar to this: -ConfigScopes site:Redmond. To limit the cmdlet scope to a single organizational unit, use syntax similar to this: -ConfigScopes "OU:ou=Redmond,dc=litwareinc,dc=com". Multiple sites or OUs can be specified by using a comma-separated list: -ConfigScopes "OU:ou=Redmond,dc=litwareinc,dc=com", "OU:ou=Dublin,dc=litwareinc,dc=com".

If no value is specified for this parameter then the role will have a global scope when it comes to user management.

InMemory

Optional

Switch Parameter

Creates an object reference without actually committing the object as a permanent change. If you assign the output of this cmdlet called with this parameter to a variable, you can make changes to the properties of the object reference and then commit those changes by calling this cmdlet’s matching Set- cmdlet.

Force

Optional

Switch Parameter

LocalStore

Optional

Switch Parameter

Suppresses the display of any non-fatal error message that might arise when running the command.

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, CsBranchOfficeTechnician, 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 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.

To create a new role you must first create a universal security group in Active Directory that shares a name with the role; for example to create a new role named DialInConferencingAdministrator you must create a security group with the SamAccountName DialInConferencingAdministrator. New-CsAdminRole will not create this group for you; if DialInConferencingAdministrator does not already exist then your command will fail. The Identity you assign to your new role must be the SamAccountName of the corresponding Active Directory group.

After creating the Active Directory security group you must then select a built-in RBAC role to serve as the template for your new custom role. You cannot create a "blank" RBAC role using New-CsAdminRole. Instead, all custom roles must be based on one of the built-in RBAC roles. This means that a custom role must, initially, have the same assigned cmdlets as one of the built-in roles. However, after the role has been created you can use the Set-CSAdminRole cmdlet to add or remove cmdlets from your custom role.

Return Types

New-CsAdminRole creates new instances of the Microsoft.Rtc.Management.WriteableConfig.Settings.Roles.Role object.

Examples

-------------------------- Example 1 ------------------------

Copy Code
New-CsAdmin -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator"

The command shown in Example 1 "clones" the RBAC role CsVoiceAdministrator. Because no additional parameters are used, the new role - RedmondVoiceAdministrators - will be an exact duplicate of CsVoiceAdministrator.

-------------------------- Example 2 ------------------------

Copy Code
New-CsAdmin -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator" -UserScopes "OU:ou=Redmond,dc=litwareinc,dc=com"

The preceding command creates a new RBAC role (RedmondVoiceAdministrator) and then configures the role to allow a single user scope: the Redmond OU. To do this, the -UserScopes parameter is included along with the following parameter value: @{Replace="OU:ou=Redmond,dc=litwareinc,dc=com". This parameter value replaces the current value of the UserScopes property with one item: the OU with the distinguished name "ou=Redmond,dc=litwareinc,dc=com".

-------------------------- Example 3 ------------------------

Copy Code
New-CsAdmin -Identity "RedmondVoiceAdministrator" -Template "CsVoiceAdministrator" -UserScopes "OU:ou=Redmond,dc=litwareinc,dc=com","OU:ou=Portland,dc=litwarein,dc=com"

The command shown in Example 3 is a variation of the command shown in Example 2; the only difference is that, in this example, 2 OUs are added to the UserScopes property. This is done by assigning a comma-separated list to the Replace method; the two items in the list represent the identifiers for the two OUs (Redmond and Portland) to be assigned to the new RBAC role.