This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

Copyright 2011 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Internet Explorer, Lync, Silverlight, SQL Server, Windows, and Windows PowerShell are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

This chapter is part of the Microsoft Lync Server 2010 Resource Kit book that is currently being developed. Chapters will be available for download while this book is being completed. To help us improve it, we need your feedback. You can contact us at nexthop@microsoft.com. Please include the chapter name.

For information about the continuing release of chapters, check the DrRez blog at http://go.microsoft.com/fwlink/?LinkId=204593.ContributorsProject Manager: Susan S. Bradley

Content Architect: Rui Maximo

Chapter Lead: Indranil Dutta

Writers: Indranil Dutta, Jens Trier Rasmussen

Technical Reviewers: Edwin Young, Thomas Lee, Tin Fan, Yong Zhang

Lead Editor: Kate Gleeson

Art Manager: Jim Bradley

Production Editor: Kelly Fuller Blue

Table of Contents

4Contributors

6Introduction

6What is the Central Management Store?

9What is Stored in the Central Management Store?

10How the Central Management Store Replicates

13Central Management Store Resilience

14Managing Central Management Store Replication

15Lync Server Control Panel Architecture

17Browser Behavior

17Lync Server Control Panel Availability

18Lync Server Role-based Access Control Architecture and Scope

22Creating Custom RBAC Roles

IntroductionWith Microsoft Lync Server 2010 communications software, configuration data about servers and services is moved to the Central Management store. The Central Management store provides a more robust, schematized storage of the data needed to define, set up, maintain, administer, describe, and operate a Lync Server 2010 deployment. It also validates the data to ensure configuration consistency.

Lync Server 2010 still uses Active Directory Domain Services (AD DS) to store basic Lync Server user information, such as the users SIP URI and phone number. User policy information is stored in the Central Management store. By using Active Directory, Lync Server 2010 ensures backward compatibility with earlier releases of Office Communications Server.

To administer servers and services, you use Lync Server Management Shell or Lync Server Control Panel. The Lync Server Management Shell is an implementation of the Windows PowerShell command-line interface with specific cmdlets for managing Lync Server 2010 pre-loaded in the environment. The Central Management Server, which runs on one Front End pool or one Standard Edition server in your deployment, replicates configuration changes to all of the servers in your deployment. The Lync Server Management Shell and Lync Server Control Panel administrative tools are installed by default on each server running Lync Server 2010.What is the Central Management Store?The Central Management store is a database that stores management data in the form of topology, configuration settings, and policy information. The repository is implemented as a XML document store (xds) on a server running Microsoft SQL Server database software. This information is stored as XML documents in the database. Central Management store services are built around this repository and replicate the management data to the servers running Lync Server 2010.

Access to the repository is provided through a Lync Server 2010 dynamic-link library (DLL) called Microsoft.Rtc.Management.Core.dll. This DLL enforces validation and scope resolution for the information stored in the Central Management store. All consumers of the Central Management store and its data, including service components and the Lync Server Management Shell, use this DLL to interact with the Central Management store. The DLL is linked to the tools and the services that implement the Central Management store.You modify the information in the Central Management store by using any of the following tools: Topology Builder, Lync Server Management Shell, or Lync Server Control Panel, as illustrated in Figure 1.

Figure 1 Interacting with the Central Management storeThe Central Management store validates any information that is written to it before it commits the data to the database. The Central Management store implements and checks many rules for dependencies and interdependencies between components and server roles. This way, the Central Management store ensures that the topology is valid and does not contain any unsupported configurations. The tools listed previously also perform this validation logic.

Note. You can run the Lync Server Best Practices Analyzer to check for and flag any issues after deployment.

The Central Management store operates as a single master with multiple replicas. In every Lync Server 2010 deployment there is a single master Central Management store and all servers running Lync Server have a local replica of the Central Management store. All updates to the Central Management store are first performed at the master. The update is then replicated to all replicas. For details about replication, see the section titled How the Central Management Store Replicates later in this chapter.We recommend that you install the Central Management store on an Enterprise Edition Front End pool so that it benefits from the high availability built into an Enterprise Edition deployment. In this type of configuration, the master xds database is located in the same SQL Server instance as the back-end databases, typically RTC. Each Front End Server in the pool replicates the xds database to a local SQL Server Express instance called RTCLOCAL. Figure 2 shows a pool with two Front End Servers, Front End 1 and Front End 2, and a Back End Server (SQL Server).

Figure 2 Central Management store database placement in an Enterprise Edition Front End poolIf you install the Central Management store on a Standard Edition server, the master xds database is located in the SQL Server Express instance called RTC. Like the Front End Servers in an Enterprise Edition Front End pool, the Standard Edition server also creates a replica xds database located in the SQL Server Express instance called RTCLOCAL, as shown in Figure 3.

Figure 3 Central Management store placement in a Standard Edition serverTo locate the Central Management store master, you look up a service control point (SCP) in Active Directory. This SCP is created under the path of the following distinguished name (DN), CN=topology settings, CN=RTC Service,DC=, with an object of type msRTCSIP-GlobalTopologySetting. This object contains the msRTCSIP-BackEndServer attribute, which specifies the fully qualified domain name (FQDN) of the SQL Server that stores the Central Management store and the instance name of the SQL Server instance in the following format: \. All Lync Server management tools use the SCP to locate and connect to the Central Management store master.

The SCP is typically created by Topology Builder when it initially publishes the topology based on information in the topology. This is the recommended method for creating the SCP. Note. You can change the location by using the Set-CsConfigurationStoreLocation SQLServerFqdn SqlInstanceName cmdlet.If you want to move the Central Management store to a new pool, you need to use the Move-CsManagementServer cmdlet. It will update the SCP to point to the new server location.

The Lync Server Management Shell Get-CsManagementConnection cmdlet shows the connection information, including the SQL Server connection string that is used when communicating with the Central Management store master. Topology Builder and Lync Server Control Panel always read and write to the Central Management store master. In the Lync Server Management Shell, many of the Get-Cs* cmdlets accept the LocalStore parameter, which displays the information found in the local replica of the Central Management store.

The local services running on Lync Server always read from the local Central Management store replica. This ensures resilience in case the Central Management store master or the network connection to the Central Management store master is not available. For details about resilience, see the section titled Central Management Store Resilience later in this chapter.The Central Management store is implemented by using the following services:

Lync Server Master Replicator Agent

Lync Server File Transfer Agent

Lync Server Replica Replicator Agent

All of these services run on the Central Management store master, and the Replica Replicator Agent service runs on every Lync Server. For details about these services, see the section titled How the Central Management Store Replicates later in this chapter.What is Stored in the Central Management Store?As described previously, the Central Management store stores configuration information for the servers in a Lync Server deployment. In previous versions of Office Communications Server, this information was stored in Active Directory, SQL Server, and Windows Management Instrumentation (WMI). So why did we decide to move it to the Central Management store? The following reasons influenced our decision to make this change in Lync Server 2010: With Office Communications Server, storing information in different places made it difficult for administrators to understand where the information was stored and which interfaces they needed to use to manipulate the data. When adding new features and functions to Office Communications Server, administrators often needed to extend the Active Directory schema with new object classes and attributes, which can cause delays. With Office Communications Server, the Edge Server role is deployed in the network perimeter and access to the corporate Active Directory in the internal network was difficult due to the large number of ports that needed to be open in the perimeter networks internal firewall. Lync Server 2010 still stores user information in the user objects in Active Directory and maintains backward compatibility by storing system-level settings in Active Directory, which enables interoperability with Office Communications Server 2007 and Office Communications Server 2007 R2.

The Central Management store stores configuration information as XML documents. The Central Management store contains the following types of information: Topology Policy Configuration You can store these types of information in the following different scope levels: Global Site Service Tag The topology document contains the topology information generated by Topology Builder. The policy document contains all of the different policies that you can configure in Lync Server 2010, including dial plan, client, and conferencing information. The configuration document contains all of the server settings that you can configure in Lync Server 2010, including certificates, call park orbit number range, and dial-in conferencing access numbers.

There is only one XML document per information type and per scope. For example, one XML document contains all dial plans with Site scope, while another XML document contains all dial plans with Global scope.

The Lync Server management tools write to the XML documents through internal programmatic interfaces provided by the Microsoft.Rtc.Management.Core.dll. Important. Direct manipulation of the XML documents is not supported.

How the Central Management Store ReplicatesAs previously described, all configuration is performed on the Central Management store master and all servers running Lync Server have a local replica of the Central Management store. Therefore, the replicas must be updated from the Central Management store master. This process of transferring information updates from master to replica is called replication. The Central Management store replication process consists of writing the Central Management store information to a local folder structure on the Central Management store master, copying that information to the replicas, applying the changes received to the replica, and then reporting status back to the Central Management store master.

The Central Management store master uses a directory file structure shared with other Lync Server components in a network share that is defined by the topology document. The name of the top-level directory is the Service ID of the Central Management store master. The tree structure is as follows: \\CMSFileStore\xds-master Where is the name of the directory selected to be the FileStore used by the Central Management store in the topology document, and is the service ID of the Central Management store service in the topology document. The directory, xds-master, contains the following subdirectories: replicas and working. The replicas directory contains a subdirectory for each of the replicas. Each subdirectory is named after the FQDN of the replica server. Within each replica directory are the following subdirectories: from-replica and to-replica, as shown in Figure 4.

Figure 4 Central Management store xds-master directory structureEach replica uses a directory structure in the network share, \\\xds-replica, to synchronize with the Central Management store master, where is the FQDN of the replica. The xds-replica directory contains the following subdirectories: from-master, to-master, and working, as shown in Figure 5.

Figure 5 Replica directory structureEvery 60 seconds, the Central Management store master determines whether a configuration change has been made to the Central Management store master and needs to be replicated. The unit of replication is the changed XML document. If a dial plan with global scope is added, the full XML document containing dial plans with global scope will be replicated. All changes that are made since the last time the task was run are batched together into a data package (that is, the data.zip file), as shown in Figure 6.

Figure 6 Central Management store data package

The size of the data package is small, typically less than 100 KB, which makes for fast replication across the network without any substantial impact on network bandwidth.

The Master Replicator Agent service generates the data package containing new changes to Central Management store and stores a copy in each to-replica directory for every Lync Server replica.

The data package must be copied to all replicas. The Central Management store master, with the exception of the Edge Server, uses the Windows file copy Server Message Block (SMB) protocol to push the data packages to the replica. Note. For details, see Server Message Block (SMB) Protocol Specification in the MSDN Library at http://go.microsoft.com/fwlink/?LinkId=217608.For Edge Servers the file copy is performed over HTTPS. The Edge Server runs a Web Service (that is, https://:4443/ReplicationWebService) on port 4443. The Web Service, ReplicationWebService, does not require that you install Internet Information Service (IIS) on the Edge Server. The ReplicationWebService is implemented as part of the Replica Replicator Agent service. The certificate used for the HTTPS channel is the server certificate issued to the internal edge of the Edge Server.

The File Transfer Agent service that runs on the Central Management store master copies the data packages from the Central Management store master to all of the replicas. The File Transfer Agent service has change notifications on all of the to-replica directories. The File Transfer Agent service is alerted when the Master Replicator Agent service places data packages in those directories. It then starts the file copy process to the from-master directory on all replicas.

Note. For details, see Obtaining Directory Change Notifications in the MSDN Library at http://go.microsoft.com/fwlink/?LinkId=217609.On the replica, the Replica Replicator Agent service has change notification on the from-master directory and gets alerted when the File Transfer Agent service has copied a data package to the replica. The Replica Replicator Agent service then extracts the data package and applies the changes to the local Central Management store on the replica. After applying the Central Management store changes, the Replica Replicator Agent service generates a status package (that is, the status.zip file). The status package contains information for the Central Management store master about the status of the application of the Central Management store changes.

The Replica Replicator Agent service places the status package in the to-master directory on the replica. The File Transfer Agent service running on the Central Management store master has change notifications configured on the to-master directory on all replicas (that is, except the Edge Servers). It is alerted about the new status package. On Edge Servers, the File Transfer Agent regularly polls the to-master directory to see if a status.zip package is placed there. Then, polling frequency is increased when the File Transfer Agent is expecting a status.zip package (that is, after it has just transferred a data.zip package to the Edge Server). The File Transfer Agent service then copies the status package from the replica to the from-replica directory on the Central Management store master for the given replica.

The Master Replicator Agent service has change notifications on all from-replica directories. It processes the status package and updates internal status information in the Central Management store.

When a Lync Server starts, the Replica Replicator Agent service generates a status.zip package to report the current replication status to the Central Management store master.

On the replica, the services running on the Lync Server are registered for change notifications to different types of XML documents in the replicas Central Management store. The services poll the local replica every 60 seconds to discover any changes to the XML documents that they are interested in.

Because it takes up to 60 seconds for the Master Replicator Agent to determine any configuration changes made to the Central Management store and up to another 60 seconds for the local services to check any configuration changes in the local replicas Central Management store, it can take up to two minutes for configuration changes made to the Central Management store to be enforced by the services running on the Lync Server. Central Management Store Resilience

We recommend that you install the Central Management store on an Enterprise Edition Front End pool to ensure the resiliency of the Central Management store. One of the Front End Servers in the pool is designated as the active Central Management store master. All Front End Servers in a pool run the Master Replicator Agent and File Transfer Agent services, but only one Front End Server is designated as the active Central Management store master.

To ensure high availability, if the currently designated Central Management store master is not responsive, a heartbeat mechanism is used to failover the active master to another Front End Server. To determine which Front End Server is designated as the next Central Management store master, run the following cmdlet in the Lync Server Management Shell:

Get-CsManagementStoreReplicationStatus CentralManagementStoreStatus

In addition, you can configure the SQL Server that contains the Central Management store for high availability by using SQL Server clustering. For details, see Getting Started with SQL Server 2008 Failover Clustering in the MSDN Library at http://go.microsoft.com/fwlink/?LinkId=217610.To protect the data stored in the Central Management store, back up the SQL Server database by using backup utilities for SQL Server. In addition, you can export the data stored in the Central Management store by running the following cmdlet:

Export-CsConfiguration Filename As previously mentioned, the services running on the Lync Server always communicate with the local Central Management store replica, not directly with the Central Management store master. If communication between the Central Management store master and the replica is disrupted, the replica fails to receive any Central Management store updates. Despite this connectivity disruption with the Central Management store master, the Lync Server services are able to continue functioning normally without the latest Central Management store updates. After communication is re-established, the local replica obtains updates from the Central Management store master.If the Central Management store master is not accessible from the Lync Server Management Shell or Lync Server Control Panel, you cannot make configuration changes (that is, add or remove settings) in the Central Management store because these configuration changes must be performed directly on the Central Management store master.

Managing Central Management Store ReplicationManaging Central Management store replication involves checking for replication status and invoking replication. To check for replication status, you run the Get-CsManagementStoreReplicationStatus cmdlet. This cmdlet returns the information shown in Table 1 for each replica in the topology.

Table 1 Output from Get-CsManagementStoreReplicationStatusItemDescription

UpToDateIndicates that the replica is up-to-date with the Central Management store master.

ReplicaFqdnFQDN of the replica.

LastStatusReportLatest date and time when the Master Replicator Agent received a status package from the replica.

LastUpdateCreationLatest date and time when the Master Replicator Agent generated a data package to the replica.

ProductVersionVersion of Lync Server.

If you run the Get-CsManagementStoreReplicationStatus cmdlet with the CentralManagementStoreStatus parameter, it displays information about the active Central Management store master. Table 2 lists the information returned by this parameter.

Table 2 Output from Get-CsManagementStoreReplicationStatus -CentralManagementStoreStatusItemDescription

LastUpdatedOnLast time the Central Management store master was changed.

ActiveMasterFqdnFQDN of the Lync Server designated as the active Central Management store master.

ActiveMasterLastHeartBeatLatest date and time when the active master sent a heartbeat.

ActiveFileTransferAgentFqdnFQDN of the Lync Server designated as the active File Transfer Agent.

ActiveFileTransferAgentLastHeartBeatLatest date and time when the active File Transfer Agent sent a heartbeat.

ActiveReplicasList of active (that is, not deleted) replicas.

DeletedReplicasList of deleted replicas (that is, servers no longer active in the topology).

To force replication, use the Invoke-CsManagementStoreReplication cmdlet. This cmdlet clears the last status report field from the Central Management store and triggers replication. Important. Use this command with caution because it generates network traffic to all servers that are running Lync Server.

Both Get-CsManagementStoreReplicationStatus and Invoke-CsManagementStoreReplication provide the optional parameter, ReplicaFqdn, which allows the administrator to specify the FQDN of a Lync Server. This scopes the action to the specified replica only.Lync Server Control Panel ArchitectureLync Server 2010 Control Panel is a scenario-driven tool that you can use to configure settings and policies, manage Lync users, show service status, and perform validation, in addition to many other administrative tasks. Lync Server Control Panel was developed using the Microsoft Silverlight browser plug-in. It uses the new data store architecture (that is, the Central Management store), where all of the persistent Lync Server service data is stored and takes advantage of the task-based model implemented in Windows PowerShell. Lync Server Control Panel replaces the administrative tools available with Office Communications Server 2007 and Office Communications Server 2007 R2. You can access Lync Server Control Panel from either a 32-bit or 64-bit browser. It is installed as part of Web Services on each Front End Server.Lync Server Control Panel decouples the UI layer from the data storage layer. The objectives for the UI and data storage are very different. Lync Server Control Panel acts as a bridge that connects the UI and data storage without strong dependencies. It supports Integrated Windows authentication and you access it over https. The benefits of using Integrated Windows authentication are that it can be coupled with IIS authentication and that Integrated Windows authentication does not pass users credentials over the network, thereby providing a seamless and more secure user experience.To access Lync Server Control Panel, administrators use the URL that includes the pool FQDN or IP address in the following format: https:///cscp. To make it easier, administrators can define a simple administrative URL (for example, https://admin or https://admin..com) in Topology Builder and then point a Domain Name System (DNS) record to the Lync Server pool. After publishing the topology, users can access Lync Server Control Panel by using this custom simple URL. Lync Server Control Panel supports concurrent usage by multiple administrators. In a large Lync Server deployment, there may be multiple data centers and multiple remote sites. In this case, multiple Lync Server Control Panel instances are installed on the data center and remote sites. All of the Lync Server Control Panel instances have the same functionality. The administrator can access any Lync Server Control Panel application to manage the tasks that he or she has the appropriate user rights and permissions to manage. Lync Server Control Panel uses the same load balancing mechanism as the Web Services. Being a web application, this may be a hardware load balancer, where the request from a client may reach different servers. So, Lync Server Control Panel keeps components stateless so that the server logic doesnt depend on possible state lost.As illustrated in Figure 7, the web client (that is, Internet Explorer) uses Windows authentication to authenticate to Lync Server Control Panel. Lync Server Control Panel calls the Lync Server Management Shell cmdlets to configure settings in the Central Management store master or Active Directory. Lync Server Control Panel follows a user/task-oriented design instead of a hierarchical data-oriented model. In other words, Lync Server Control Panel is organized according to user actions instead of data structures.

Figure 7 Interacting with Lync Server Control PanelLync Server Control Panel consists of two parts: client-side components (that is, in the browser) and server-side components, as illustrated in Figure 8. The client-side components were developed using the Silverlight platform and they run within the browser. At the core of the server-side component is an HTTP/SOAP web service managed by Lync Server Web Services. The Lync Server Control Panel Web Services calls local Windows PowerShell cmdlets to run administrative configuration tasks. The client side is responsible for presenting the Lync Server management UI. The server side provides the data and action services.

Figure 8 Overview of Lync Server Control Panel

Browser BehaviorThe screen/browser resolution for Lync Server Control Panel client is 1024x768, whereas the minimum supported client solution is 800x600. As a Silverlight web application, the browsers native back and forward button functionality is not available when you are using Lync Server Control Panel. If you use the browsers refresh button, you effectively lose the entire Lync Server Control Panel web session and client-side cache because the Lync Server Control Panel web application is reloaded from the Lync Server.Lync Server Control Panel Availability

Lync Server Control Panel always ensures application availability. As a web application, multiple Lync Server Control Panel instances can be load balanced to achieve availability. Because Lync Server Control Panel functionality is provided by Web Services, the availability of the Web Services cluster provides high availability for Lync Server Control Panel. As long as at least one server running Web Services is available in the pool, Lync Server Control Panel can connect to it to provide full functionality to the administrator. Lync Server Role-based Access Control Architecture and Scope

Figure 9 Interacting with RBACRole-based access control (RBAC) allows administrators to delegate specific user rights and permissions to other administrators to perform a subset of the administrative tasks possible. With RBAC, a users ability to carry out specific administrative tasks depends on the RBAC roles that are assigned to the user. RBAC provides a list of cmdlets that the user is allowed to run based on the RBAC roles that the user is a member of. Each user is given a restricted Windows PowerShell namespace. The namespace is populated based on the users identity and the RBAC information retrieved from the RBAC data in the Central Management store. When a user runs cmdlets, RBAC performs enforcement of the rules by verifying the target of the operation against the allowed scopes for that user. If the user passes the cmdlet and scopes checks, the cmdlet is run under the identity of the Lync Server management subsystem. RBAC doesnt provide any policy enforcement at the cmdlet level (that is, not at the parameter level of each cmdlet). RBAC allows a user to run or not run a cmdlet.Important. RBAC restrictions work only on administrators working remotely, using either Lync Server Control Panel or the Lync Server Management Shell. A user that is directly logged on to a server (that is, sitting at the server) running Lync Server is not restricted by RBAC. Therefore, physical security of your Lync Server is important to preserve RBAC restrictions.RBAC roles determine the UI functionality that a user can view and edit (that is, read or write) in Lync Server Control Panel. An RBAC role is, in effect, a collection of Lync Server Management Shell cmdlets. A user can be assigned to one or more roles and can only run the cmdlets associated with those roles. The set of users or service settings a user can configure is determined by RBAC scopes. The scope of an RBAC role is defined as the criteria used to evaluate the set of objects that the set of cmdlets associated with a role can view or operate on (that is, modify or remove). RBAC scope types fall into the following categories: User Scope TypesDefine user-level scoping, including user-level entitlements, and per-user policies assignment tasks.

Server Scope TypesDefine server-level scoping (that is, non-user, deployment-level scoping), including server roles/service management, setting configuration, and server operational tasks.

In Lync Server, you can assign an RBAC role to a Universal security group in Active Directory only. The assigned role is associated with all users of that security group. This is valid even if some of the members of the security group are actually not enabled for Lync Server. Nested security groups inherit the RBAC role assigned to the parent security group. So, if a user is a member of a Universal group and that Universal group becomes a member of a different security group, the user is assigned the RBAC roles that are assigned to both security groups. Lync Server provides built-in RBAC Universal security groups that are visible in Active Directory Users and Computers, as shown in Figure 10. Lync Server 2010 automatically creates these security Universal groups and their names are exactly the same as the corresponding RBAC role name.

Figure 10 Active Directory Users and Computers showing Lync Server RBAC Universal security groups

In Lync Server, there are nine built-in RBAC roles, called standard roles. To quickly find these roles, run the following cmdlet in the Lync Server Management Shell:Get-CsAdminRole | Where {$_.IsStandardRole eq true } | ft Identity

The output for this cmdlet is as follows: Identity ------------------------

CSAdministrator

CSVoiceAdministrator

CSUserAdministrator

CSResponseGroupAdministrator

CSLocationAdministrator

CSArchivingAdministrator

CSViewOnlyAdministrator

CSServerAdministrator

CSHelpDesk Each of these built-in roles has a number of cmdlets associated with it, and some of the cmdlets might be available in more than one role. For example, Get-CsDialPlan and Grant-CsDialPlan are available to multiple roles, including CsUserAdministrator, CsAdministrator, and CsVoiceAdministrator. All three of these roles need to be able to view the available dial plans and associate them with users or sites.To know which cmdlets belong to these built-in roles, you can expand the cmdlets attribute by running the following cmdlet in the Lync Server Management Shell:

Get-CsAdminRole | Where {$_.IsStandardRole eq true } | ft Identity,cmdlets wrapThis cmdlet returns a list of all of the RBAC roles associated with all of the cmdlets, as shown in Figure 11.

Figure 11 List of RBAC roles associated with cmdletsTo get a list of all cmdlets associated with a specific built-in-role, say CsServerAdministrator, run the following command:Get-CsAdminRole -Identity CsServerAdministrator | Select-Object ExpandProperty Cmdlets

RBAC roles are also enforced by Lync Server Control Panel, which means that users only see the sections in Lync Server Control Panel that they have the appropriate user rights and permissions to use. In the following Figures 12 and 13, you can see the difference in the options that are available in Lync Server Control Panel when a user assigned to the CsAdministrator role logs on (Figure 12) compared to when a user assigned to the CSArchivingAdministrator role logs on (Figure 13).

Figure 12 Lync Server Control Panel options for a CsAdministrator

Figure 13 Lync Server Control Panel options for a CsArchivingAdministrator

To see all of the RBAC roles associated with a particular user (for example, Peter Smith), run the following cmdlet:Get-CsUser "Peter Smith" | ForEach-Object {Get-CsAdminRoleAssignment Identity $_.SamAccountName}

Creating Custom RBAC Roles

Some organizations might need to administer Lync Server at a more granular level. For example, lets say that the Toronto Lync User Admins are allowed to administer all Lync users in the Toronto Active Directory organizational unit (OU) only, or the Redmond Archiving Administrators are allowed to administer archiving properties for all Lync Server pools that are part of the Redmond Lync Server site only, as defined in Topology Builder. To do this, you can create new groups that have the appropriate user rights and permissions of any of the nine built-in RBAC roles, and you apply them to a specific Active Directory OU or a Lync Server site. You cannot mix and match cmdlets to create a completely new group. You must work with the nine built-in RBAC roles, also referred to as templates, when you create custom groups in Windows PowerShell. A user can be a member of several of these custom groups. The users effective user rights and permissions are cumulative of the user rights and permissions provided by each of the custom groups of which he is a member.

To create a custom RBAC role, you must first create a Universal security group in the Users container in Active Directory. Using New-CsAdminRole cmdlet, create a custom RBAC role based on one of the nine built-in templates, as shown in Figure 11. Then, you can apply the custom RBAC role to a Lync Server site or to OUs. If you do not create the security group first, you receive the following error message:Security group not found for the given sAMAccountName : .Cannot save role-based access control (RBAC) role because the associated security group does not exist in Active Directory. Create the security group in Active Directory and then try again.After you have created the Universal security group and the custom RBAC role, assign the built-in RBAC roles that have the user rights and permissions that you want the custom role to have. For example, to assign the CsUserAdministrator role to the Universal Group, TorontoUserAdmin, with authority over the OU, OU=Toronto,DC=Contoso,DC=com, run the following cmdlet:New-CsAdminRole TorontoUserAdmin Template CsUserAdministrator UserScopes OU:OU=Toronto,DC=Contoso,DC=comThe output is as follows:Identity : TorontoUserAdmin

SID : S-1-5-21-4049948038-3165229088-4274728906-1203

IsStandardRole : False

Cmdlets : {Name=Disable-CSUser, Name=Enable-CSUser, Name=Get-CSAdUser, Name=Get-CSUser..}

ConfigScopes : {Global}

UserScopes : {OU:OU=Toronto,DC=Contoso,DC=com}

Template : CsUserAdministratorYou can also create a custom RBAC group (for example, RedmondArchivingAdmin), and assign the RBAC group to the Lync Server site called Redmond so that users assigned to this RBAC group can manage archiving options of all Lync Server pools under the Redmond Lync Server site only, as defined in Topology Builder. But, before you can assign the custom RBAC group to a site you need to know the SiteId number. To get the site number, run the Get-CSSite cmdlet. The output for this cmdlet is as follows:Identity : Site:Redmond

SiteId : 3Services : {PstnGateway:192.168.100.145, FileStore:cs-sql01.contoso.com, UserServer:cspool01

.contoso.com, Registrar:cspool01.contoso.com...}

Pools : {192.168.100.145, cs-sql01.contoso.com, cspool01.contoso.com, cs-mon.contoso.com}

FederationRoute : EdgeServer:cs-r2edge.contoso.com

Description : US Main Office

DisplayName : Redmond

SiteType : CentralSite

ParentSite :After you know the SiteId number (for example, 3 in the example output), you can then use the following cmdlet to assign all members of the RedmondArchivingAdmin group to have full archiving management rights on all Lync Server pools in the Redmond Lync Server site:New-CSAdminRole RedmondArchivingAdmin Template CsArchivingAdministrator ConfigScopes Site:3The output for this cmdlet is as follows:Identity : RedmondArchivingAdmin

SID : S-1-5-21-4049948038-3165229088-4274728906-1204

IsStandardRole : False

Cmdlets : {Name=New-CsArchivingPolicy, Name=Get-CsArchivingPolicy, Name=Set-CsArchivingPo

licy, Name=Remove-CsArchivingPolicy...}

ConfigScopes : {Site:1}

UserScopes : {Global}

Template : CsArchivingAdministratorAs mentioned earlier, remember that it is not possible to remove cmdlets or parameters when you create a custom RBAC role in Lync Server.To get information about custom RBAC roles, run the following command:Get-CsAdminRole | Where-Object {$_.IsStandardRole eq $False}

The output for this cmdlet is as follows:Identity : TorontoUserAdmin

SID : S-1-5-21-4049948038-3165229088-4274728906-1203

IsStandardRole : False

Cmdlets : {Name=Disable-CSUser, Name=Enable-CSUser, Name=Get-CSAdUser, Name=Get-CSUser...}

ConfigScopes : {Global}

UserScopes : {OU:OU=Toronto,DC=Contoso,DC=com}

Template : CsUserAdministrator

Identity : RedmondArchivingAdmin

SID : S-1-5-21-4049948038-3165229088-4274728906-1204

IsStandardRole : False

Cmdlets : {Name=New-CsArchivingPolicy, Name=Get-CsArchivingPolicy, Name=Set-CsArchivingPo

licy, Name=Remove-CsArchivingPolicy...}

ConfigScopes : {Site:1}

UserScopes : {Global}

Template : CsArchivingAdministrator

To remove the Toronto OU from the RBAC role TorontoUserAdmin, you can user the following parameter value: @{Remove="OU:OU=Toronto,DC=Contoso,DC=com"}. This syntax deletes the OU with the DN "OU:OU=Toronto,DC=Contoso,DC=com" from the collection of OUs already in the UserScopes property. So, you run the following cmdlet:Set-CsAdminRole -Identity "TorontoUserAdmin" -UserScopes @{Remove="OU:OU=Toronto,DC=Contoso,DC=com"}For a list of Windows PowerShell scripts that you can use to manage RBAC, see the Lync Server Windows PowerShell blog at http://go.microsoft.com/fwlink/?LinkId=194834. Microsoft Lync Server 2010 Resource Kit Server AdministrationPage 22