Working with Lync Online Policies
Summary: Use Windows PowerShell to Manage Office 365 using Windows PowerShell cmdlets, scripts, and batch processes.
Considering the fact that Lync Online has a Get-CsOnlineUser cmdlet and a Set-CsUser cmdlet you might think that user management in Lync Online works in the same way as user management in Exchange. For the most part, however, that’s not the case. Consider this screenshot from the Lync Online Admin center:
.png "External communications option.")
As you can see, Alex Darrow is allowed to communicate with federated users from outside the organization (Lync users), and is also allowed to communicate with users who have accounts on Windows Live (People on public IM networks). Based on that, you might logically expect that:
The Get-CsOnlineUser cmdlet returns information about Alex Darrow’s external communication capabilities.
The Set-CsUser cmdlet enables you to configure these external communication capabilities.
For better or worse, though, neither of these expectations are exactly true. Admittedly, the Get-CsOnlineUser cmdlet does return information about Alex’s external communication capabilities, but in a somewhat roundabout way. Take a look at the last line in this sample output:
VoicePolicy :
MobilityPolicy : MobilityEnableOutsideVoice
ConferencingPolicy : BposSAllModality
PresencePolicy :
VoiceRoutingPolicy :
RegistrarPool : sippoolbl20a07.infra.lync.com
DialPlan :
LocationPolicy :
ClientPolicy :
ClientVersionPolicy :
ArchivingPolicy :
LegalInterceptPolicy :
PinPolicy :
ExternalAccessPolicy : FederationAndPICDefault
As it turns out, many Lync Online user account properties are configured by using policies. (Policies are simply collections of settings that can be applied to one or more users.) When we ran Get-CsOnlineUser against Alex Darrow’s Lync account, it tells us that Alex has been assigned an external user access policy named FederationAndPICDefault. What does that mean? To answer that question, we have to take a look at how the FederationAndPICDefault policy has been configured. That’s something we can do by running this command:
Get-CsExternalAccessPolicy -Identity "FederationAndPICDefault"
In turn, we should get back something similar to this:
Identity : Tag:FederationAndPICDefault
Description :
EnableFederationAccess : True
EnableXmppAccess : False
EnablePublicCloudAccess : True
EnablePublicCloudAudioVideoAccess : True
EnableOutsideAccess : True
It’s the values within these policies that tell us what Alex truly can or cannot do when it comes to communicating with federated users. To begin with, the EnableOutsideAccess property must be set to True for Alex to be able to communicate with people outside the organization. (That property, by the way, does not appear in the Admin center. Instead, the property is automatically set to True or False based on the other selections that you make.) As for the other two properties of interest:
EnableFederationAccess indicates whether the user can communicate with people from federated domains.
EnablePublicCloudAccess indicates whether the user can communicate with Windows Live users.
What that means is we don’t directly change federation-related properties on Alex’s account (for example, Set-CsUser –EnableFederationAccess $True). Instead, we assign Alex an external access policy that has the desired property values preconfigured for us. If we want Alex to be able to communicate with federated users and with Windows Live users he must be assigned a policy that allows those types of communication.
Complicated? Well, not really: it’s really more different than it is complicated. What it comes down to is this: if we want to know whether or not someone can communicate with users from outside the organization, we have to:
Determine which external access policy has been assigned to that user.
Determine which capabilities are or are not allowed by that policy.
For example, in Alex Darrow’s case we can do that by using this command:
Get-CsOnlineUser -Identity "Alex Darrow" | ForEach {Get-CsExternalAccessPolicy -Identity $_.ExternalAccessPolicy}
It’s a different way of doing things, but it works: find the policy assigned to the user, then find the capabilities enabled or disabled within that policy.
Having said that, there are couple of things to keep in mind here. First of all, there are no cmdlets for creating or for modifying policies: you must use the policies pre-supplied by Office 365 If you want to take a look at the different policies available to you, you can use these commands:
Get-CsClientPolicy
Get-CsConferencingPolicy
Get-CsDialPlan
Get-CsExternalAccessPolicy
Get-CsHostedVoicemailPolicy
Get-CsPresencePolicy
Get-CsVoicePolicy
Note
In case you’re wondering, a Lync Online dial plan is a policy in every respect except the name. The name “dial plan” was chosen instead of, say, “dialing policy” in order to provide backward compatibility with Office Communications Server and with Exchange.
For example, to look at all the voice policies available for your use just run this command:
Get-CsVoicePolicy
Note
That returns a list of all the voice policies available to you. Keep in mind, however, that not all policies can be assigned to all users; this is due to various restrictions involving licensing and geographic location. (The so-called “usage location.”) If you want to know the external access policies and the conferencing policies that can be assigned to a particular user, use commands similar to these:
Get-CsConferencingPolicy –ApplicableTo "Alex Darrow"
Get-CsExternalAccessPolicy –ApplicableTo "Alex Darrow"
The ApplicableTo parameter limits the returned data to policies that can be assigned to the specified user (for example, Alex Darrow). Depending on licensing and usage location restrictions, that might represent a subset of all the available policies.
Second, if we take another look at the sample output we got back for Alex Darrow, we’ll see that several policy-related properties are blank:
VoicePolicy :
MobilityPolicy : MobilityEnableOutsideVoice
ConferencingPolicy : BposSAllModality
PresencePolicy :
VoiceRoutingPolicy :
RegistrarPool : sippoolbl20a07.infra.lync.com
DialPlan :
LocationPolicy :
ClientPolicy :
ClientVersionPolicy :
ArchivingPolicy :
LegalInterceptPolicy :
PinPolicy :
ExternalAccessPolicy : FederationAndPICDefault
In some cases that doesn’t matter: some of these properties (such as ClientVersionPolicy) are not used with Office 365, while others (for example, MobilityPolicy) can only be managed by Microsoft support personnel. But what about the other properties, properties such as VoicePolicy and ClientPolicy? These properties are blank. Does that mean that Ken Myer doesn’t have a voice policy or a client policy?
The answer to that is: no. With Lync Online, users must be managed by a policy of some kind. If a valid policy-related property is blank, that means that the user in question is being managed by a global policy.And what exactly is a global policy? A global policy is a policy that is automatically applied to a user unless he or she is specifically assigned a per-user policy. (We’ll talk about per-user policies in a minute.) Because we don’t see a client policy listed for Ken Myer that can only mean one thing: Ken Myer is managed by the global policy. If we want to see what that actually means (that is, if we want to see what client-related things is Ken actually allowed to do), we need to take a peek at the global client policy:
Get-CsClientPolicy -Identity "Global"
And yes, that‘s not necessarily ideal: it might be easier if the Get-CsOnlineUser cmdlet returned data that looked like this:
ClientPolicy : Global
But it doesn’t. On the bright side, at least now you know how to work around the whole idea of a “blank” policy-related property.
Assigning Per-User Lync Online Policies