A big change to Lync Server 2010 is the addition of
the Lync Server Management Shell (LSMS). The LSMS is built on
Microsoft’s PowerShell command and scripting environment and is really
the core of what drives Lync Server 2010 management. Many administrators
will use the Lync Server Control Panel (LSCP) by default because they
are more familiar with a graphical user interface, but as time goes on
it should become apparent that much of Lync server management can be
done in a more efficient manner through the LSMS.
Many organizations that use Microsoft Exchange Server
are already familiar with how the Management Shell operates. When
Microsoft first introduced the Exchange Management Shell as part of
Exchange Server 2007, many administrators were frustrated and even
intimidated by having some functionality only available in a
command-line interface. The same is now true with the LSMS for previous
administrators of LCS and OCS. Oftentimes, the same team within an
organization who manages Exchange is responsible for managing Lync. If
administrators have experience with the Exchange Management Shell, the
change might not seem quite as drastic. For those entirely new to a
command-line interface, it might take some time to feel comfortable.
Benefits of the Management Shell
For administrators primarily familiar with using
graphical user interface (GUI) tools to manage systems, the LSMS might
seem a bit intimidating at first, but Lync Server administrators new to
PowerShell should spend some time getting acquainted with the new
command-line based toolset for several reasons. First, some tasks and
actions simply do not exist within the LSCP, so for these types of
features, administrators must resort to using the LSMS. For example, in
Live Communications Server and Office Communications Server, changing
the port that a Front End Server used for SIP communication involved
just a few check boxes within the management console. With Lync Server
2010, the only way to modify the port or add an additional port is to
use the LSMS.
Note
A good example is when administrators want to allow a
Lync Server Front End to also listen on port 5060 for unencrypted SIP
communication in addition to the standard 5061 for SIP over TLS. This
isn’t possible in the Lync Server Control Panel, but to enable this
feature using the Lync Server Management Shell, use the following
cmdlet:
Set-CsRegistrar registrar:<Pool FQDN> -SipServerTcpPort 5060
Another major benefit of the LSMS is that bulk tasks
are much easier to accomplish. With the older products, a task such as
moving users between pools or modifying assigned policies was typically
done through the management consoles and involved running through
multiple pages of a wizard. Selecting the correct users to modify was
also somewhat difficult because there was no breakdown of groups or
divisions within the GUI. In the end, it was apparent that performing
bulk tasks needed some attention from the product group. With the LSMS,
administrators have an incredible amount of flexibility in how to
perform certain tasks. It is easy for administrators to select a group
of users based on an attribute and modify all policies or move users
quickly.
Note
Although bulk changes are easy to make with the LSMS,
that also means it can be easy to make a mistake and have it affect
many user accounts. Be sure to always test bulk changes on a smaller
subset of users. If possible, have a test or development environment
where bulk changes can be verified before they run against the
production systems.
Tip
Some organizations familiar with PowerShell use
custom scripts to provision new user accounts. Scripting these kinds of
operations greatly reduces the chance for a human error to affect the
account creation.
Just imagine how many times the wrong dial plan,
voice policy, or conferencing policy can be applied to a new account
when left as a manual process. For small organizations this isn’t
typically an issue, but for larger companies having a standardized,
automated method is a necessity.
This kind of PowerShell-based provisioning has been
fairly typical for Exchange mailboxes since Exchange 2007. Because OCS
did not have any native PowerShell support, organizations were forced to
continue using VBScript or some other method to automatically enable
new accounts for OCS. With the LSMS, an entire workflow script can be
used to create new accounts. When a new user joins the company, a
PowerShell script is used to automatically create
the new user account, place it in the correct organizational unit,
provision a home folder, create an Exchange mailbox on the correct
database, enable the user for Lync, and assign the correct voice and
conferencing policies. Not only is the chance for error reduced, but
consider how much time is saved by not requiring extra work.
Management Shell Basics
Tasks are performed in PowerShell through commands called cmdlets.
Cmdlets each have a specific function and begin with a verb, such as
Get or Set, indicating what action will be taken. The remainder of the
cmdlet determines what specific object will be viewed or acted upon. 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.
Note
When loading the Lync Server Management Shell, 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 (LSMS) 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.
Note
All the cmdlets in Lync Server 2010 include the Cs
designator, which stands for Communications Server. The actual name
change from Communications Server 14 to Lync Server happened fairly late
in the product life cycle, and the cmdlet naming was never updated.
The first parameter in any cmdlet is referred to as the identity,
which signifies what object will be acted upon. Not all Get cmdlets
require an identity to be provided and, when omitted, it will return a
list of all the matching objects. 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 using a Set command 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 previous 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 piping multiple objects to another cmdlet they will
each run through the destination cmdlet. Consider a scenario where 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.
Tips and Tricks
There are quite a few shortcuts and tricks that can
be used within the Lync Server Management Shell to save time. This
section discusses a few tips that might make using the Management Shell a
bit easier and more efficient.
Use the Tab Key
Instead
of typing a full cmdlet name, begin typing the first few letters after
the action verb and press the Tab key. The Management Shell
automatically cycles through the cmdlets that match the string already
entered. For example, typing Get-CsP and then pressing Tab automatically
changes to Get-CsPinPolicy. Pressing Tab again changes to Get-CsPool.
Use Tab to go forward through the list and press Shift+Tab to cycle
backward. The Tab key can also auto-complete parameters inside the
cmdlet, so it is handy when recalling the exact parameter name.
Skip the Identity
Although the identity can make retrieving an object
specific and is a required parameter when changing an object, it’s not
required to type the entire identity parameter. If the identity is not
explicitly referenced, the first string after the cmdlet is assumed to
the identity. For example, the following two commands are equivalent in
functionality, but one requires fewer characters:
Get-CsVoicePolicy –Identity Executives
Get-CsVoicePolicy Executives
Surround Spaces with Quotation Marks
When referencing objects or names that have spaces or
special characters, make sure the entire text string is enclosed in
quotation marks or single quotation marks. When PowerShell detects a
space, it assumes the next character will be the beginning of a new
parameter. Without surrounding the text string in quotation marks, it
might lead to commands that fail. Both single and double quotation marks
are acceptable. For example, when trying to retrieve the user Tom
Pacyk, this command generates an error:
To successfully return the correct user, use the following command:
Leverage Get-Help
Included within all the Lync Server Management Shell
cmdlets is a built-in help reference. To retrieve assistance with any
cmdlet, simply type Get-Help followed by the name of the cmdlet. For
example, to get assistance with the Set-CsDialPlan cmdlet, type
This help request returns a description of the
cmdlet’s purpose, the full syntax and parameters available in the
cmdlet, and a summary of what the cmdlet does. More information can also
be requested using the –Examples, -Detailed, and –Full flags at the end
of the command. –Examples returns sample commands with the correct
syntax, -Detailed returns a description of each parameter, and –Full
returns the complete documentation available.
Having
this help reference available without manually searching through
documentation is incredibly useful. It can also come in handy when
you’re having trouble remembering a specific cmdlet name. In these
cases, wildcards can be used to search through the documentation for a
match. For example, the following command returns a list that displays
Set-CsBandwidthPolicyServiceConfiguration and Set-CsBlockedDomain:
