Exchange Server 2010 provides administrators with
three primary administrative tools: The first two, the Exchange
Management Shell and the Exchange Management Console, were both
introduced with Exchange Server 2007. The third, the Exchange Control
Panel, is new to Exchange Server 2010 and provides some exciting
possibilities.
The Exchange Management
Shell is a command-line interface, allowing administrators to run single
commands or complex scripts to simplify redundant tasks. The Exchange
Management Shell can be utilized to configure every aspect of an
Exchange Server environment.
The Exchange Management
Console has a graphical user interface (GUI). Nearly as powerful as the
Shell, the Console can be used to configure most of the aspects of an Exchange Server environment.
New to Exchange Server 2010
is the Exchange Control Panel, which enables personnel to administer
some aspects of the Exchange Server environment through a web interface.
Unlike the Management Console or the Management Shell, which are
designed and intended to be used only by Exchange Server administrators,
the Exchange Control Panel is designed to also enable end users to
self-manage certain aspects of their accounts.
Exchange Management Shell
The Exchange Management
Shell (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 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 v1, Exchange Server 2010 is built on
PowerShell v2, which has several enhancements that distinguish it from
the previous version.
Exchange Server
2010 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 2010 server
via a remote connection utilizing an Internet Information Server (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 v2 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.
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 RBAC control 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— All the commands available in the Windows command prompt (cmd.exe)
are also available to the EMS. Administrators can not only run these
commands, but also can 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, 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.
