2. Exchange Management Shell
The
EMS is the engine that powers all Exchange administrative tools. A
powerful management tool in its own right, the EMS is also utilized by
both the Exchange Management Console and the Exchange Control Panel to
process actions initiated in their interfaces.
Introduced
in Exchange Server 2007, the Exchange Management Shell is a
command-line management interface. Administrators had been screaming
for years for a command-line tool that was powerful enough to enable
scripted changes of Exchange Server objects, and the Exchange
Management Shell was well received.
Tasks
that had to be done manually within the confines of the graphical user
interface (GUI) management application in pre-2007 versions could now
be scripted, allowing administrators increased flexibility for
repetitive tasks. The Exchange Management Shell looks similar to the
DOS command prompt (cmd.exe), in that it opens a window with a
black background and a text interface. However, you notice immediately
that certain commands and errors are highlighted in yellow or red text
rather than the traditional monochromatic command prompt.
With
the Exchange Management Shell, administrators can manage every aspect
of Exchange Server, including the creation and management of new email
accounts, the configuration of Simple Mail Transfer Protocol (SMTP)
connectors and transport agents, or properties of database stores. In
fact, every task that can be accomplished with the Exchange Management
Console can be accomplished from the command line in the EMS, but the
opposite is not true.
Note
When the EMS was first released, there were many commands that had
to be performed in the shell because many configuration options were
not available in the EMC. As much as administrators enjoyed the new
capabilities of the command-line interface, they did not like being
told “you have to use it all the time.” Over time, more and more
functionality was added back into the Exchange Management Console.
With the EMS, administrators have a
powerful yet flexible scripting platform that is much easier to take
advantage of than using Microsoft Visual Basic scripts—previously the
only way to script changes in the Exchange Server environment. As
described by Microsoft, “What once took hundreds of lines in Visual
Basic scripts can now be accomplished easily with as little as one line
of code.”
The EMS uses an object model
that is based on the Microsoft .NET platform. This enables the shell
commands to apply the output from one command to subsequent commands
when they are run.
Whereas Exchange Server
2007 used PowerShell 1.0, Exchange Server 2013 is built on PowerShell
3.0, which has several enhancements that distinguish it from the
previous version.
Exchange Server 2013
also utilizes Windows Remote Management (WinRM) 2.0. Whether an
administrator is connecting to a local server or one halfway around the
world, EMS always connects to the desired Exchange Server 2013 server
via a remote connection utilizing an Internet Information Services
(IIS) virtual directory. This holds true even when administrators are
running the PowerShell command against the server they are currently
logged on to. Due to this capability, the ability to perform
PowerShell-based Exchange Server management does not require Exchange
Server binaries to be installed on the requesting client, so 32-bit
clients that have PowerShell 3.0 with WinRM 2.0 installed can be used
for remote PowerShell administration.
The
supported client OS platforms include the x86 and x64 versions of
Windows Vista, Windows Server 2008, Windows Server 2008 R2, Windows 7,
Windows Server 2003, Windows Server 2003 R2, and Windows XP.
2.1 Exchange Management Shell Basic Concepts
The
Exchange Management Shell has a number of command functions, support
options, and customization features. The following is a list of some of
the basic concepts administrators should be aware of:
• Objects—The
collection of properties that represents each of the pieces that make
up an Exchange Server environment. An object can refer to a user
mailbox, a server, a connector, or one of many other configurable items.
• Cmdlets—A
cmdlet, pronounced “command-let,” is a specialized .NET class that
performs a particular operation. Cmdlets are the smallest unit of
functionality in the EMS. Similar in appearance to the built-in
commands in other shells (such as the DIR or CD
commands in a Microsoft command prompt), cmdlets can be run
individually or combined in scripts. There are hundreds of cmdlets
provided for Exchange Server–specific management tasks.
• Parameters—Parameters
are elements that provide information to the cmdlet. Parameters can
either identify an object or its attributes to act upon or can control
how the cmdlet performs its task.
• Restricted PSSession—By
implementing the Role Based Access Control (RBAC) model, the EMS can
restrict available cmdlets and parameters to only those that the user
has access to run. For example, if the user does not have the access to
create new mailboxes, the New-Mailbox cmdlet will not be presented to them.
• Identity—Identity
is a special parameter that can be used with most cmdlets to give
access to the unique identifiers that refer to a particular object. By
using the identity parameter, administrators can specify
the particular object they want to retrieve, modify, or delete. To
reduce unnecessary keystrokes, the identity parameter was created as a positional parameter. When running a cmdlet, the first argument is assumed to be the identity parameter, so running the command get-mailbox –identity "linkin" will produce the same results as get-mailbox "linkin".
• Pipelining—Before
the EMS, one of the biggest shortcomings of scripting in the Exchange
Server environment was the lack of ability to take the output of one
command and utilize it directly as the input for other commands. Within
the EMS, pipelining allows exactly that. Administrators have the
ability to string cmdlets together, using one cmdlet to gather data,
passing the results to a second cmdlet that filters the data to a
smaller subset, and then supplying the result to a third cmdlet to act
on.
• Object-oriented data handling—Because
the resulting output from any cmdlet in the Exchange Management Shell
is an object, all output can be acted upon and processed by other
commands with little to no changes. Commands that are intended to work
together on particular feature sets accept the output from other
commands in the same feature set.
• Access cmd.exe commands—Nearly all the commands available in the Windows command prompt (cmd.exe) are also available to the EMS, although there are sometimes
slight differences in syntax. Administrators can not only run these
commands, but can also take the output from those commands and perform
actions based on that output.
• Trusted scripts—Administrators
have long been concerned that the ability to run scripts in an
organization (especially when logged in with administrative
credentials) could have disastrous results. To prevent this from
happening, by default the Exchange Management Shell requires that all
scripts be digitally signed before they are allowed to run. This
feature is intended to prevent malicious users from inserting a
dangerous or harmful script in the EMS. Before a script can be run, the
administrator must specifically “trust” it, helping to protect the
entire organization.
• Profile customization—The
EMS provides a powerful, easy-to-use interface with the default
installation, but administrators might want to customize the appearance
of the interface, create shortcuts for commonly used commands, or
specify specific commands to automatically run when the EMS starts. All
these items can be configured using a customized Exchange Management
Shell profile.
• Tip of the day—Although
perhaps not as impressive as the preceding features, a welcome feature
of the EMS is the display of a Tip of the Day each time the Exchange
Management Shell is opened. The Tip of the Day offers advice on how to
perform specific tasks within the shell, listing commands and proper
syntax for their use.
