Identities, Scopes, and Tenants
Topic Last Modified: 2013-08-15
Many of the Windows PowerShell cmdlets used to manage Lync Online require you to be very specific about the item that you are trying to manage. For example, when you run the Set-CsUserAcp cmdlet, you must indicate which user you are trying to manage. This makes sense. Unless you specifically tell the cmdlet which user account to manage, the Set-CsUserAcp cmdlet has no idea which user’s audio conferencing information should be modified. For this reason, each time you run the Set-CsUserAcp cmdlet, you’ll need to include the Identity parameter, followed by the Identity of the user account to be modified:
Set-CsUserAcp -Identity "Ken Myer" -TollNumber "14255551298" -ParticipantPassCode 13761 -Domain "fabrikam.com" -Name "Fabrikam ACP"
If the term Identity always referred to the Identity of a user account, there would be little cause for confusion. When you are dealing with people (users, contacts, and so on), Identities refer to the individual users themselves. However, items other than user accounts also have Identities. When you are dealing with components of the Lync Online service—policies, configuration settings, and so on—the term Identity means something slightly different. For example, consider this command:
Get-CsMeetingConfiguration -Identity "global"
In this case, the Identity "global" refers to the scope of the meeting configuration settings. Scope is a term used in Lync Online (and in Lync Server) to designate spheres of management. By default, policies and settings always have a global scope. When you first set up your Lync Online account you'll have, by default, a collection of global policies and settings—global meeting configuration settings, a global external access policy, a global dial plan, and so on.
These global policies and settings were introduced in Microsoft Lync Server 2010 to help ensure that all users and all components would always, in some way, be managed. This was not necessarily true in Microsoft Office Communicator 2007 R2. Depending on how you accessed the system, you could potentially end up in a largely unmanaged state (typically, because Group Policy could not be applied to your user account). In contrast, in Lync Server and in Lync Online, nothing is ever left unmanaged. This is because, in lieu of anything else, global policies and settings will always be enforced.
What do we mean by "in lieu of anything else"? Well, in the case of Lync Online, it’s possible to create policies at the tag scope, or sphere of management. Policies created at the tag scope (also known as the per-user scope) take priority over policies created at the global scope. In other words, a per-user policy will always take precedence over a global policy. For example, you might have two external user access policies. The global policy prohibits users from communicating with people who have accounts on public instant messaging (IM) providers, such as Windows Live. The per-user policy, AllowPublicIMCommunication, allows communication with public IM providers.
You might also have two users: Ken Myer and Pilar Ackerman. Ken Myer has been assigned the per-user policy. Pilar Ackerman has not been assigned a per-user policy; that is, she is managed by the global external access policy. The following table shows which user (if any) can communicate with public IM providers:
|Policy Settings||Ken Myer||Pilar Ackerman|
Global policy setting for public IM providers
Per-user policy setting for public IM providers
User can communicate with public IM providers
As you can see, Ken Myer is allowed to communicate with public IM providers. This is because the settings in the per-user policy assigned to him override the settings in the global policy. Pilar Ackerman cannot communicate with public IM providers. This is because she is managed by the global policy, and the global policy prohibits such communications.
Per-user policies must be created for you by Office 365 Support. After the policies are created, you can then assign them to users by using the appropriate Grant-Cs cmdlet (for example, Grant-CsExternalAccessPolicy). Per-user policies are easy to identify because the policy Identity always begins with the tag prefix. For example:
Identity : tag:AllowPublicIMCommunication
|The tag prefix dates back to the early development days of Lync Server 2010. In those days, per-user policies were referred to as tag policies and were identified by the tag prefix. These policies are now more accurately referred to as per-user policies, and the tag scope is more accurately referred to as the per-user scope. However, for technical reasons, the tag prefix was never changed.|
Another key term used when working with Lync Online and Windows PowerShell is tenant. When you set up a Lync Online account, your new deployment is assigned a tenant ID number, which is a globally unique identifier (GUID) similar to this:
A few of the Lync Online cmdlets require you to enter the tenant ID whenever you run the cmdlet. You must enter the tenant ID even if you have logged on to, and only have, one tenant. Fortunately, you do not have to memorize the tenant ID. You can retrieve your tenant ID at any time by running the following Windows PowerShell command:
Get-CsTenant | Select-Object TenantId
Of course, knowing things such as the difference between the global scope and the per-user scope (or the tag scope) is only half the battle. It’s also important to know when (or even if) you can use these scopes. The same is true for Identities and the tenant parameter. The following topics describe how the different Lync Online cmdlets use Identities, scopes, and the tenant parameter:
- Cmdlets that Use Only the Global Scope
- Cmdlets that Use the Global Scope and the Tag Scope
- Cmdlets that Use a User Identity
- Cmdlets that Use a User Identity and the Tag Scope
- Cmdlets that Use the Tenant Parameter
- Cmdlets that Use a Conferencing Provider Identity
- Cmdlets that Do Not Use a Scope or an Identity