Management Shell Basics

Tasks are performed in PowerShell through commands called cmdlets. Cmdlets each have a specific function and their names begin with a verb, such as Get or Set, indicating what action will be taken. The remainder of the cmdlet name determines what specific object will be viewed or acted on. The Lync Server Management Shell is built on top of the Windows PowerShell engine, meaning that everything you can do within Windows PowerShell can also be done within the Lync Server Management Shell. The opposite, however, is not true.

When the Lync Server Management Shell is loading, an extensive list of more than 500 custom cmdlets is loaded on top of the base PowerShell cmdlets available. These new cmdlets are specific to Lync Server and enable administrators to manage Lync components through the Management Shell.

Most of the cmdlets within the Lync Server Management Shell are consistent in their naming approach because they follow a format consisting of a verb, a hyphen, the letters “Cs,” and, lastly, an item.

This might seem long, but it makes sense when you view the actual cmdlets. Commands to view the configuration or properties of an item all begin with Get, and when changing or assigning new properties, the cmdlet begins with Set. For example, to view the properties of a particular Lync user account, the cmdlet Get-CsUser can be used. To set one of the properties for a user account, such as a phone number, the Set-CsUser cmdlet can be used.

The first parameter in any cmdlet is referred to as the identity, which signifies what object will be acted on. Not all Get cmdlets require an identity to be provided, and when it is omitted, a list of all the matching objects is returned. For example, running Get-CsUser -Identity sip:[email protected] returns the properties of only a single user, but simply running Get-CsUser with no identity specified returns a list of all users and their properties.

When a Set command is used, though, an identity must be specified so that the Management Shell knows which object should be modified. Additionally, the attribute of the object being modified must be specified. Only the attribute being changed must be included, so if other attributes are staying the same there is no need to include them. For example, if a user needs to be enabled for Enterprise Voice and assigned a Line URI, the command looks like the following string:

Set-CsUser -Identity sip:[email protected] -EnterpriseVoiceEnabled $true -LineUri tel:+12223334444

Commands can also be strung together, or “piped” to one another. When piped to another cmdlet, the object passed from the first cmdlet is assumed to be the identity in the second cmdlet. Continuing the preceding example, an equivalent command to the Set-CsUser example is the following string:

Get-CsUser -Identity sip:[email protected] | Set-CsUser -EnterpriseVoiceEnabled $true -LineUri tel:+12223334444

This might not seem beneficial when a single user is involved, but when multiple objects are piped to another cmdlet, they will each run through the destination cmdlet. Consider a scenario in which an organization wants to enable all users who have a display name starting with the letter T for Enterprise Voice. First, the Get-CsUser cmdlet is used, but to return only the users whose display name begins with T, a Filter parameter is used. For those familiar with filtering using the Where-Object cmdlet, the Filter parameter uses the same syntax and operators. The Where-Object cmdlet can also be used here, but the built-in Filter parameter is more straightforward:

Get-CsUser -Filter {DisplayName -like "T*"}

This can be built on even further by piping the results to a Set-CsUser cmdlet where the users can be enabled for Enterprise Voice:

Get-CsUser -Filter {DisplayName -like "T*"} | Set-CsUser -EnterpriseVoiceEnabled $true

This short string of cmdlets can enable thousands of users for Enterprise Voice in a much faster method than using the Lync Server Control Panel.