On-going user management in Lync typically involves changing, deleting, and reassigning existing Lync user policies to specific groups of users to expose or limit features for such things as Conferencing, External Access, and Client capabilities.
When reassigning Lync user policies, you will likely need to select a subset of Lync users based on their current policy and then make follow-on modifications to those Lync user objects. This blog post contains tips on do this and how to properly delete existing user policies.
Finding and Managing Lync Users with an Existing Policy
Doing user policy management in the Lync Server Management Shell will likely utilize the Get-CsUser cmdlet. This cmdlet, combined with the power of the PowerShell pipeline can be used to find Lync users with a specific criteria and take action on them.
The challenge of using the Get-CsUser cmdlet to return a set of Lync users that have been assigned a specific policy is that the logical and comparison operators (e.g. “-eq”) do not work with an existing policy names like they do on other Lync user properties.
For example, assume you need to find all Lync users that have the Lync Conferencing Policy set to “Allow Video”.
Based on all the Lync PowerShell examples in the documentation, you could be forgiven if you thought either of these cmdlet’s would work (they do not):
Get-CsUser -Filter {ConferencingPolicy –eq “Allow Video”}
Get-CsUser -Filter {ConferencingPolicy -match “Allow Video”}
Get-CsUser | Where-Object {$_.ConferencingPolicy -eq “Allow Video”}
The three commands are similar but behavior is slightly different and none of them will give you the correct results.
Using the Get-CsUser cmdlet with the Where-Object cmdlet will return nothing – even if there are users with the “Allow Video” conferencing policy, and using either of the Get-CsUser cmdlet’s with the –Filter parameter will produce this error:
Get-CsUser : Cannot bind parameter ‘Filter’ to the target. Exception setting “Filter”: “Query not supported for operator: “”
query: “ConferencingPolicy -match “Allow Video”" position: “20″”
At line:1 char:19
+ Get-CsUser -Filter <<<< {ConferencingPolicy -match “Allow Video”}
+ CategoryInfo : WriteError: (:) [Get-CsUser], ParameterBindingException
+ FullyQualifiedErrorId : ParameterBindingFailed,Microsoft.Rtc.Management.AD.Cmdlets.GetOcsUserCmdlet
Note: you can successfully use the –eq operator to test for a $Null policy such as “Get-CsUser -Filter {ExternalAccessPolicy -eq $Null}”.
The Solution
The problem stems from the fact that the policy property values returned by Get-CsUser are of type “Microsoft.Rtc.Management.ADConnect.Schema.OCSADUser”, and we are trying to match the value against a ‘String’.
One solution therefore is to type cast the value of the existing policy name to a string so that we can compare apples-to-apples.
For example, this will work:
Get-CsUser | Where-Object {[String] $_.ConferencingPolicy -eq “Allow Video”}
(To appease the PowerShell purists, I should note it is always better (safer) to fully qualify the String type, so it is better to use “[System.String]” instead of just “[String]”).
Another solution is to use the “-match” operator to match a string using a regular expression.
Get-CsUser | Where-Object {$_.ConferencingPolicy -match “Allow Video”}
I am not sure exactly what happens under the PowerShell convers, but this does work and I believe the “-match” operator is forcing (casting) the existing policy value into a string type.
You can also use the comparison operators –notmatch and –like (with wildcards) for different types of searches. This Microsoft TechNet reference page lists all of the comparison operators that can be used.
Deleting Existing User Policies
If a subset of Lync users are changing from a specific user-level policy to the Global default policy, you might be inclined to just delete the existing policy. For example, if you want 20 users with the Lync Conferencing Policy named “Allow Video” to now use the Global default conferencing policy, you might consider just deleting the “Allow Video” policy rather than setting the conferencing policy for these 20 users to $null.
Although the Lync Control Panel will give you a warning when attempting to delete a policy that is assigned to one or more users, it will let you. And in this example, the desired end-goal will be achieved – the users will be now use the Lync default Global policy – however this is not the correct way to do this.
Behind the scenes Lync will replace the previously assigned policy name with a numerical reference, and whenever a user management action is done in the Lync Control Panel or Management Shell, a warning will be produced for all users affected.
This is an example of the warnings produced for 6 users who had their existing conferencing policy deleted:
The Solution
A better way to completely remove an existing policy is to make sure no Lync users are assigned to it, and then delete the policy.
To remove a user policy in the Lync Management Shell for a specific group of users, you can just set the policy to $null using the appropriate Grant-Cs cmdlet. For example, to remove the conferencing for all Lync users who currently have the “Allow Video” conferencing policy, we could use the Grant-CsConferencingPolicy cmdlet as follows:
Get-CsUser | Where-Object {$_.ConferencingPolicy -match “Allow Video”} | Grant-CsConferencingPolicy –PolicyName $Null
Or, for example, to remove any existing conferencing policy on all users in the AD City of Boston, you could use:
Get-CsUser -LdapFilter l=Boston | Grant-CsConferencingPolicy –PolicyName $Null
(Note: the lowercase L represents the AD attribute “locale” which represents the AD field “City”)
Once the policy assignment has been removed from all users who were assigned to it, the policy can safely be deleted to avoid the above warnings.
Tip – if you have the warnings described above, or other warnings that you already know about and can safely ignore, you can use the –”WarningAction:SilentlyContinue” parameter on any of the cmdlet’s to ignore the warnings until you correct the underlying issue.
What has been talked about in this blog post applies to all the per-user Lync policies, namely:
- ExternalAccess
- VoicePolicy
- ConferencingPolicy
- ClientPolicy
- PresencePolicy
- ArchivingPolicy
- LocationPolicy
- PinPolicy
- MobilityPolicy
- HostedVoiceMailPolicy
In all cases the cmdlet used to assign a per-user policy is “Grant-Cs{PolicyType}”.
References
).
Twitter