1. Understanding the Exchange Management Shell
The
Exchange Management Shell in Exchange 2007 is a command-line interface
that allows Exchange administrators to manage, check, and report on any
Exchange objects. These objects include mailboxes, mailbox stores,
storage groups, servers, connectors, and the Exchange organization
itself—anything that can be managed in Exchange Server 2007 can be
managed by the Exchange Management Shell.
The
Exchange Management Console (EMC) is actually a graphical user
interface (GUI) for the Exchange Management Shell, or EMS. Each task or
operation that an administrator does using the Exchange System Console
is actually calling an EMS command or series of commands.
The
Exchange Management Shell is built on a Microsoft Windows technology
called PowerShell. PowerShell, formally code-named Monad, is as
powerful (or more powerful) than some programming languages. It plugs
into the .NET runtime, also called the common language runtime. An
administrator can sit at a PowerShell prompt and access almost
everything in Windows.
The Exchange
Management Shell and Windows PowerShell are extremely powerful, where
virtually anything can be written and scripted from the shell.
PowerShell is a fully featured command-line shell, similar to a Bash
prompt. It is also an extremely powerful administrative scripting
tool—think Perl or Ruby with AWK, SED, and Grep
thrown in. And all of this is based on .NET—so administrators have
direct access to the entire .NET common language runtime, plus the
ability to script existing COM (ActiveX) and Windows Management
Instrumentation (WMI) objects, similar to what can be done with
VBScript.
Because EMS is based on
PowerShell, administrators have access to the full set of features
built in to PowerShell, plus extensions written by the Exchange 2007
team. These Exchange 2007 specific commands, or cmdlets, leverage the
simplicity and power of PowerShell to perform common and some
not-so-common Exchange tasks.
Administrators
can now do almost every single administrative task with an interactive
command line. EMS can be used to quickly check settings, create
reports, check the health of the Exchange servers, or, best of all,
automate all of the administrator’s frequent operations.
The
PowerShell team, led by the brilliant architect of PowerShell, Jeffrey
Snover, realized that Windows needed a command-line interface that
would allow administrators to do everything from the command line. GUIs
can only do as much as they are written to do. Some changes are made in
the Registry, some in Active Directory (AD) through Active Directory
Services Interface (ADSI), and others in less often used or difficult
to manage components like the Exchange metabase or Internet Information
Services (IIS).
Scripting and automation
are key to lowering total cost of ownership to Exchange administrators.
By providing a simple platform that allows administrators to create,
save, and distribute their own cmdlets, EMS allows administrators to
easily extend Exchange functionality and administrative tasks that are
appropriate for their support structure and line of business.
Since
the beginning, Exchange administrators have requested ways to manage
all the buttons and knobs that are built in to the server. The GUI only
allows the administrator to do as much as the GUI was programmed to do.
Now that all these objects and settings are available through EMS,
administrators are free to develop, customize, save, and distribute
their own cmdlets to Exchange support staff.
The
power of EMS can be used to automate many different types of tasks.
Imagine creating 10,000 test user accounts for a test lab with one line
of code or setting a 200-MB mailbox quota on all mailboxes in the
organization with one line. That’s the power of the Exchange Management
Shell.
The
Exchange Management Shell and PowerShell replace VBScript, WMI, ADSI,
LDP, and more—all within a single command-line interface. Tasks that
used to require specialized scripting knowledge can now be easily
learned using extensive help within the shell.
Cmdlets
that administrators create can be modified to do other tasks.
Administrators will quickly build a set of cmdlets that they will use
and recycle into new and more complex sets of functions.
A
common question asked by administrators is whether complex scripting is
required in EMS to do simple tasks. Do administrators have to learn
complex syntax and command switches to manage Exchange? Exchange
Management Shell is extremely powerful, very easy to learn, and helps
to simplify many tasks that previously had to be done by developers or
programmers.
When the Exchange Server 2007
team started designing the Exchange cmdline and scripting interface,
they made absolutely sure that 80% of Microsoft customers, who normally
have little or no scripting experience, can still use the
PowerShell/Exchange command line to automate or perform their tasks.
PowerShell
comes in a dynamic link library (DLL) form as well so developers can
include it in their own applications. Administrators, users, or
developers can write their own cmdlets to extend the functionality of
PowerShell. These cmdlets can either be written using PowerShell script
or they can be compiled into a .NET assembly using any programming
language that targets the common language runtime.
EMS
makes it easier to administer Exchange 2007 by making administration
more safe, easy, and fun. It improves the developer experience by
making it easier to add command-line management capabilities using
Microsoft .NET. It improves the administrative experience by enabling
information technology (IT) professionals to write secure automation
scripts that can run locally or remotely.
2. Understanding the Exchange Task Model
Four
major groups of tasks are performed in Exchange 2007 administration.
Each of these groups and tasks can be fully managed using EMS. The rich
command-line interface in EMS provides more granularity than the
Exchange Management Console.
Recipient management tasks—
These tasks include all facets of mailbox, contact, and distribution
group management, including creation, moves, deletions, and
modifications.
Organization management tasks— These tasks include managing global rules, email life cycle policies, and unified messaging dial plans.
Server management tasks—
These tasks include managing and configuring all Exchange 2007 server
roles, including Mailbox server, Client Access server, bridgehead
server, gateway server, and Unified Messaging servers.
Diagnostic tasks— These tasks include queue management, reporting, and analysis. Performance monitoring and alerts also fall into this group.
Tasks are further broken down into categories based on server role or features:
Edge server— Managing Active Directory Application Mode (ADAM), receive, and send connectors
Bridgehead, CAS, Mailbox, and Unified Messaging roles—
Managing transport rules, Outlook Web Access configuration, storage
group and mail store configuration, mailbox configuration, and unified
messaging configuration
Antispam— Managing content filtering, recipient filtering, IP Allow and Block filters, SenderID, and Sender Reputation settings
Email life cycle— Creating, managing, and deleting Exchange 2007 Email Life Cycle folders
Transport— Managing hub transport rules and policies
Rules— Creating, managing, and deleting global rules, internal rules, external rules, and journal rules
Understanding EMS Is the Back End to the Exchange Management Console
The
Exchange Management Console is simply a GUI to EMS. Whenever an
operation is performed in EMC, it calls a set of cmdlets in EMS and
presents the results back to the GUI.
Everything
an administrator can do in EMC can be done in EMS, but not always vice
versa. If the Exchange 2007 team were to add every configuration
setting to the EMC, it would be much too complicated. Their goal was to
put the most common administrative tasks in EMC.
When
administrators perform most operations in EMC, the EMS command used to
execute the task is presented in the GUI, similar to the screen shown
in Figure 1.
The
administrator can copy the code, edit it in a text editor if desired,
and run it again (for example, against all servers in the organization).
When
any Exchange Server 2007 role is installed on a server or the
administrative tools are installed on a management workstation, the
.NET Framework, PowerShell, and Exchange Server 2007 cmdlets are
installed automatically. The Exchange Management Shell is launched from
the Microsoft Exchange menu after you install Exchange Server 2007 and
looks similar to the screen shown in Figure 2.
Understanding Cmdlets as the Core to EMS
A
cmdlet is a lightweight command that is used in the PowerShell and
Exchange Management Shell environments. Within that environment, the
PowerShell command interpreter (PS.exe) executes these cmdlets within the context of automation scripts.
Cmdlets differ from commands in other shell environments in the following ways:
Cmdlets are instances of .NET classes, not standalone executables.
Cmdlets can be created with as few as a dozen lines of code.
Cmdlets
do not, in general, do their own parsing, error presentation, or output
formatting. Parsing, error presentation, and output formatting are
handled by a common engine that is provided by PowerShell.
Cmdlets
process input objects from the pipeline, rather than from streams of
text, and deliver the objects as output to the pipeline.
Cmdlets are record-oriented, processing a single object at a time.
As an example, the get-mailbox
cmdlet returns all the mailbox objects on a server. It does this by
binding to Active Directory, enumerating every user object in the
domain, and returning all objects that have a valid populated homeMDB attribute.
Exchange
cmdlets enforce strict rules and validation on configuration, unlike
ADSIEdit, LDP, or VBScript. That means you cannot accidentally update a
value for an object with an invalid value using the Exchange Management
Shell. It also means that you can use the EMS to correct invalid values
automatically. This can be done by simply getting and setting the
current values for any object.
