by Christopher Wallick, BT
Well we’ve made it into the New Year and from my point of view 2011 is going to be a very busy year. So, in this edition of “Snippets from the Shell” I thought I’d take a moment to focus on some basic user administration that you’ll probably come across fairly frequently.
When a user is enabled for Enterprise Voice certain attributes are set on the user object. These attributes (or properties if we’re looking at the Lync Server 2010 Central Management Store) determine such things as which voice policy will be applied to the user, the dial plan that will tell the user’s Lync client how to normalize numbers the user types in, and amongst other things, whether or not the user’s voicemail is being served by a hosted Exchange implementation. Once all these attributes are set the user goes about his or her business happily consuming Enterprise Voice Services.
Now, let us suppose the user is transferred from, say, San Francisco to Chicago. Obviously, we’ll have to update or change the property values for those attributes that deal with Enterprise Voice. Whilst there are a number of ways we can change these values, let’s look at how we might try to change the user’s voice policy setting.
You might think that you could simply get the CsUser properties and pass all that information to a variable (for the sake of this example let’s use $user), identify the sub-property value (i.e. $user.VoicePolicy), and set the value of the sub-property to the new voice policy. Unfortunately this won’t work because the cmdlet wasn’t built that way. In this case you’ll have to “grant” the user the ability to use the new voice policy, as shown in the following example:
Grant-CsVoicePolicy –Identity JUser –PolicyName ChicagoVoicePolicy
You can also pipe the results of Get-CsUser to the Grant-CsVoicePolicy cmdlet. In any event this will probably save you some time if you’ve got to reset the voice policy on a number of users through a script.