From an Exchange perspective, Windows PowerShell provides a way to perform tasks quickly and simply in a variety of manners, from one-off interventions that process one or
more Exchange objects to complex scripts that perform tasks such as mailbox provisioning. Most administrators cut their teeth with PowerShell by using the Exchange Management
Shell (EMS) to do simple things, like 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, control ActiveSync, update Active Directory with user safe lists, 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—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, there was no way for
administrators to 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 3-1 illustrates the central role that Windows PowerShell now plays in the Exchange architecture and how it provides a central place to encapsulate business logic that
underpins the Exchange setup program, the Exchange Management Console (EMC), the Exchange Control Panel (ECP), and the EMS.
Exchange’s use of Windows PowerShell to implement functionality presented by the graphical user interface (GUI) of EMC and the setup program is probably the most extensive of
any Microsoft application. As explored throughout this book, the options presented by EMC 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. It’s also worth emphasizing that 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 them through role-based access control (RBAC).
RBAC is a huge shift in the way that Exchange manages and grants permissions to users that is designed to function across a range of different environments, from a single-server
organization to an organization composed of a mixture of on-premise and hosted servers. The need to accommodate such a wide range of environments is also the reason Microsoft has moved from local PowerShell (where all commands are executed on a local server) to remote PowerShell (where commands are redirected through Microsoft Internet Information
Services [IIS] for execution on a target server). We’ll get to the details of just how remote PowerShell and RBAC work together in the Exchange Server 2010 version of EMS shortly.
organization. The RTM release of Exchange 2010 includes 584 cmdlets that are added by EMS to join the standard set of Windows PowerShell cmdlets, including cmdlets to work with
the system registry, the file system, variables (including environmental variables), and so on. The number of cmdlets grows again to 619 in Exchange 2010 SP1. For example, the Export-
Mailbox and Import-Mailbox cmdlets that are used to export and import mailbox data from Outlook personal storage (PST) files are replaced by the New-MailboxExportRequest and New-MailboxImportRequest cmdlets and other associated cmdlets used to control the requests.
By comparison, Exchange 2007 includes 394 cmdlets, 26 of which are removed in Exchange 2010 (largely because of the demise of storage groups). The 216 new cmdlets provided in
Exchange 2010 reflect the new functionality in the product, such as the introduction of the RBAC model, mailbox archives, and the Database Availability Group (DAG), along with the
expansion of existing functionality such as messaging records management.
Windows PowerShell has been at the heart of Exchange since Exchange 2007, and its use and syntax are fundamental skills for administrators to master. In fact, many of the more
hardcore Exchange administrators prefer EMS to EMC 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 Windows PowerShell found in other chapters. To begin, let’s review the biggest change that Microsoft has made to EMS in Exchange 2010: the transition
from a purely local implementation to remote PowerShell and its associated technology.
Once we understand how to connect to EMS, we’ll go on to review how to use cmdlets to get work done.
Exchange Server 2007 was the first major Microsoft server product to embrace Windows PowerShell extensively. Windows PowerShell has a relatively short history, and its 1.0 release
exhibited some of the flaws that you’d expect. Inconsistencies in syntax are easily overcome, but the lack of remote capability was more serious because it required the installation of
Windows PowerShell and its snap-in (set of cmdlets) for Exchange on any workstation or server from which you wanted to perform management tasks. In reality, this shortcoming is often overlooked because Exchange administrators are accustomed to having to install software before they can operate. Installing software is an acceptable requirement i environments where all the servers are under your control and within your own network, but it causes problems when you want to manage servers remotely. The Microsoft introduction
of online services where companies will be able to run their Exchange environments inside large Microsoft datacenters means that remote management has taken on new importance.
Exchange 2010 includes many new features designed to ease the transition to online services, and remote PowerShell provides the fundamental building block for management.
The combination of remote PowerShell with RBAC allows administrators to manage objects residing on a server in a remote datacenter as easily as you can manage objects on a local
Exchange 2010 extends the concept of remote management to support the remote execution of commands in a secure manner using HTTPS and a Kerberos-based encryption mechanism that is easily manageable through firewalls (assuming that port 80 is open). Remote PowerShell is used for all EMS sessions in Exchange 2010. Even if you are logged on to an Exchange server and want to use EMS to change a property of that server, EMS still creates a remote session to the local server to do the work. The same applies for EMC, because Exchange creates a remote session when you log on to connect to a server in the local Active Directory site to retrieve information about the organization and then display it in the console. In effect, remote PowerShell replaces local PowerShell in Exchange 2010 for all server roles except Edge servers. The sole exception is for commands used during setup, which continue to execute locally. The removal of local PowerShell and the concentration on the combination of remote PowerShell and RBAC as the basis for administrative control over Exchange components is a major change in the product. The implementation of remote PowerShell for Exchange 2010 separates business logic into code that runs on the client and code that runs on the Exchange server. It is based on common Windows components such as Windows PowerShell 2.0 and the WS Management model (WS-Man and Windows Remote Management, WinRM). The discussion at http://blogs.msdn.com/powershell/archive/2009/01/06/manage-winrm-settings-with-wsman -provider.aspx provides useful background about how Windows PowerShell remoting is built on top of WinRM. Collectively, the Windows components combine to provide an effective ability to perform Exchange management operations remotely.
The logic for replacing local PowerShell with the remote model is simple. Just like the change in Exchange 2007 to force all messages to flow through the transport system so that a single common place existed to apply features such as transport rules, remote PowerShell forces Exchange administration to flow through RBAC so that a PowerShell session will only ever include the cmdlets necessary to do the job. The logic for keeping local PowerShell on Edge servers is simple, too. These servers are isolated from the rest of the organization so they do not have access to the RBAC roles. Anyone who logs onto an Edge server as an administrator operates in a management context of just that server and has complete control over that server. However, he cannot affect any other server or object in the Exchange organization.
The need to support hosting platforms such as Microsoft Business Productivity Online Services (BPOS) was a major influence on Exchange’s move to remote PowerShell. Providing
a secure and controllable mechanism that permits administrators to execute privileged commands to control the subset of objects that they own inside an infrastructure that is
controlled and managed by someone else is always a difficult task, especially when all the data have to pass across the Internet. Exchange 2007 controls access to its management
cmdlets through access control lists (ACLs) that are linked to Active Directory accounts. If the ACLs on your account mark you as an Exchange administrator, you can use Windows
PowerShell to manage Exchange; if not, you can’t. However, in an online services environment where many different companies share the same multitenant server and storage
infrastructure, it is highly unlikely that you will share the same Active Directory. Trust relationships and directory synchronization provide answers that have been used in hosting
environments, but these solutions often require a good deal of effort to set up and maintain. Microsoft takes a new approach to the management of permissions in Exchange
2010 with the introduction of RBAC. The concept is not new and has been used in previous authentication or identity management systems on UNIX and other platforms. What’s different here is its application to provide Exchange with a method to extend RBAC so that roles apply remotely.
How to flow remotely
To understand how remote PowerShell and RBAC work together, let’s examine how an administrator might create a new mailbox on a remote server. In this example, the administrator
works on a help desk and has been assigned a role that allows her to create new mailboxes and update the properties of existing mailboxes. We also assume that the user’s account is enabled to use remote PowerShell. In many cases, people in specialist roles such as help desk personnel will use the EMC or the ECP to perform tasks, but an experienced Exchange administrator might prefer to use a command-line interface because of its power and flexibility when compared to either EMC or ECP.
Next figure lays out the various components used by remote PowerShell from the local PowerShell host on a workstation or server across the network to IIS and the PowerShell
application running there. The other components are the PowerShell engine and the complete set of cmdlets available to Exchange 2010, the Exchange authorization library that
handles the interpretation of roles in terms of the cmdlets that each RBAC role can use, and the Active Directory driver used to read data from Active Directory. For the purpose of this
discussion we’ll assume that the account used has been assigned a role such as Recipient Management and is enabled for remote PowerShell. If you are unsure about the account’s
status, you can enable it to use remote PowerShell as follows:
Set-User –IdentityAccountName –RemotePowerShellEnabled $True
All PowerShell sessions flow through IIS because even a local connection goes through localhost.
All Exchange 2010 servers support IIS and the PowerShell virtual directory, or vdir, and all are members of the Exchange Trusted Subsystem security group and therefore can manipulate any object in the organization.
If you run EMS on a workstation or server that has the Exchange management components installed, EMS creates a remote session automatically as part of its initialization process. If
you run PowerShell on a workstation that doesn’t have the Exchange management components installed, you will have to specify the name of the server with which you want to
work. This is done with the New-PSSession cmdlet, passing the name of the server to which to connect in the form https://fqdn/PowerShell/. This cmdlet creates a secure authenticated
connection to IIS running on the target server and begins a session there by checking the role held by the account that initiates the connection.
IIS uses the RBAC mechanism to check the user’s role and associated permissions via the Exchange Authorization Library (a new component in Exchange 2010). The Exchange Authorization Library (or ADDriver) connects to Active Directory to use it as the definitive source of information about accounts and supplements these data with its knowledge
about the Exchange-specific roles that administrators have assigned to users. During a PowerShell session, ADDriver connects to a domain controller in the local site to fetch
data from Active Directory and keeps this connection throughout the session (something referred to as DC affinity). This is different from the behavior that exists in Exchange 2007
because all PowerShell sessions on a server run in the same process, so you cannot have a static setting because it might be inappropriate for some sessions. In Exchange 2007, each
PowerShell session functions in its own process and you have complete control over the Active Directory settings. Many PowerShell cmdlets support the –DomainController parameter
to allow you to connect to a specific domain controller (specifying the fully qualified domain name [FQDN]) should the need arise. Things are a little more complicated in a hosted environment where you are connected to your local network but need to work with Exchange data in a forest maintained by the hosting provider. In this instance, a directory synchronization process occurs to synchronize the basic account information from the local Active Directory forest and the data held in the Active Directory forest managed by the hosting provider.
A role group defines the set of administrative actions that a user is allowed to perform inside Exchange and can be resolved into a set of PowerShell cmdlets that the user is
allowed to use within her PowerShell session. Because our user works with mailboxes as defined by the Recipient Management role group, the set of cmdlets that she can use
includes commands with easily identified purposes such as New-Mailbox, Set-Mailbox, Get-Mailbox, and so on. Unlike the situation with Exchange 2007, where the complete set
of cmdlets is available after you load the Exchange snap-in to a PowerShell session, RBAC ensures that the user can execute only the cmdlets required to perform her role. If you
are an Exchange administrator who holds the Organization Management role, you’ll have access to almost the full set of cmdlets (to gain access to the full set, you have to grant your
account access to some minor roles). However, if your account has been assigned only the roles necessary to be able to work with recipients, you’ll see just the cmdlets covered by the
roles assigned to you.
Users are not normally aware that they are restricted in terms of available cmdlets unless they attempt to use one to which they do not have access. The point is that they shouldn’t
care that they can’t use hundreds of cmdlets, many of which do obscure things like setting properties on messaging connectors or one-off operations such as creating a new DAG.
Instead, RBAC makes sure that users can only access the cmdlets that they need to get their job done.