From an Exchange perspective, Windows PowerShell provides a
way to perform tasks quickly and simply in a variety of manners, from
one-off interventions to process one or more Exchange objects to
complex scripts to perform tasks such as mailbox provisioning. Most
administrators cut their teeth on PowerShell by using the Exchange
Management Shell (EMS) to do simple things, such as using Get-Mailbox
to report on a mailbox’s properties and Set-Mailbox or Set-CASMailbox
to set a property, before moving on to the more esoteric commands to
manipulate connectors or control the ability of devices to connect
through ActiveSync and so on. The saying is that almost anything is
possible with Windows PowerShell, and this is certainly true when you
dedicate enough energy and time to mastering the language, not to
mention the time necessary to scan the Internet for useful examples of
scripts that can be adapted to meet your needs.
Prior
to Exchange Server 2007, business logic was scattered in components
throughout the product. The management console did things—even simple
things like setting a property on a server—by using different code and
logic than in the setup program, and the application programming
interfaces (APIs) included in the product usually provided a third way
to approach a problem. The result was a total lack of consistency,
duplication of code, and a tremendous opportunity to create bugs in
multiple places. In addition, administrators could not automate common
tasks to meet the needs of their organization; essentially, if an
Exchange engineer didn’t code something into the product, it couldn’t
be done.
Figure 1
illustrates the central role Windows PowerShell now plays in the
Exchange architecture and shows how it provides a central place to
encapsulate business logic that underpins the Exchange setup program,
the Exchange Administration Center (EAC), the mailbox options that
users can update through Outlook Web App, and the Exchange Management
Shell (EMS).
The
way Exchange uses Windows PowerShell to implement business
functionality is probably the most extensive of any Microsoft
application. As explored throughout this book, the options presented by
EAC to work with mailboxes, connectors, servers, and other objects
invariably result in a call to one or more PowerShell cmdlets that
actually do the work. The functionality presented to administrators,
specialist users (those who perform a subset of administrative tasks
such as maintaining user details), and normal users is all based on
PowerShell.
The exact scope and range of the functionality
presented to any individual user is determined by the permissions
granted to him through role-based access control (RBAC). RBAC is
designed to function across a range of environments, from a
single-server organization to an organization composed of a mixture of
on-premises and hosted servers. The need to accommodate such a wide
range of environments is also why Microsoft has moved from local
PowerShell (by which all commands are executed on a local server) to
remote PowerShell (by which commands are redirected through Internet
Information Services [IIS] for execution on a target server). The
details of just how remote PowerShell and RBAC work together in EMS are
covered shortly.
At the time of writing,
Exchange 2013 RTM CU2 includes 965 cmdlets that are added to the
standard set of Windows PowerShell cmdlets, including cmdlets to work
with the system registry, file system, variables (including
environmental variables), and so on that are available in an EMS
session. Depending on the RBAC role groups of which your account is a
member, the number of cmdlets available to you might vary.
Collectively,
the set of EMS cmdlets manages the objects and the properties of the
objects that form Exchange. Objects include mailboxes, servers,
transport rules, connectors, and so on. You can determine the exact
number of cmdlets Exchange owns by using the following command (this
command doesn’t work with Exchange Online):
Get-ExCommand | Measure-Object | Select Count
By
comparison, Exchange 2007 includes 394 cmdlets, Exchange 2010, 584; and
the RTM version of Exchange 2013, 958. The hundreds of new cmdlets
included in Exchange 2013 and subsequently augmented through cumulative
updates reflect the new functionality in the product such as the
introduction of site mailboxes and data loss protection policies, along
with the expansion of existing functionality such as the changes to
compliance.
PowerShell use and syntax are fundamental
skills for Exchange administrators to master. In fact, many Exchange
administrators prefer EMS to EAC because of the additional flexibility
that EMS provides. This chapter lays out the basics of Windows
PowerShell and sets the stage for the examples of PowerShell found in
other chapters. To begin, review how the Exchange management tools
actually connect to PowerShell.
