Exchange 2010 began the necessary transformation from a
model that assumed an administrator would always have some form of
physical access to a server to the point at which remote management has
become the norm. Remote PowerShell provides the fundamental building
block for connectivity to remote systems. The combination of remote
PowerShell and RBAC enables administrators to manage objects residing
on a server in a remote datacenter as easily as managing objects on a
local server.
Note
You
can think of Windows PowerShell as implemented in Exchange Server 2007
as “local PowerShell” because cmdlets are executed in a local process.
The only element of remote access in Exchange 2007 is when you pass the
–Server parameter to identify a server against which to execute a
command. Even so, if data are needed from a remote server, such as
fetching a set of mailbox objects, it is retrieved across the network
and processed locally.
Exchange
2010 and Exchange 2013 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 now used for all EMS sessions. 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 on the
local server to do the work. The same applies for EAC 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 has replaced local PowerShell for all server roles except
edge servers. The sole exception is for commands used during setup,
which continue to execute locally. Remote PowerShell separates business
logic into code that runs on the client and code that runs on the
Exchange server. The logic for replacing local PowerShell with the
remote model is simple. Just as the change in Exchange 2007 forced all
messages to flow through the transport system so that a common place
existed to apply features such as transport rules, remote PowerShell
forces all aspects of Exchange administration to flow through RBAC so
that tight control can be achieved over the actions an
administrator—or, indeed, a user—is allowed to perform.
An RBAC
role group defines the set of administrative actions a user is allowed
to perform inside Exchange and can be resolved into a set of PowerShell
cmdlets the user is allowed to use within her PowerShell session. After
it is created, a PowerShell session is populated with cmdlets by
reference to the RBAC role groups of which the user is a member so that
it will only ever include the cmdlets that have been assigned to an
administrator through her membership in role groups. Thus, the fact
that an administrator is not a member of a particular role group is
reflected in that any PowerShell session she initiates will never be
able to call the cmdlets associated with the management group. Consider
the case of an administrator who is a member of the Organization
Management role group, typically believed to be the all-powerful role
for Exchange management. Even though membership in the Organization
Management role group grants a user access to the vast majority of
Exchange cmdlets, out of the box, it does not grant access to the set
that controls movement of data into and out of mailboxes. To protect
user data, the Mailbox Import-Export role has to be explicitly assigned
to any user who wants to perform these tasks, even those who are
already members of the Organization Management role group.
The
need to support massively scalable, multitenant platforms such as
Office 365 was a major influence on the Exchange move to remote
PowerShell. Providing a secure and controllable mechanism to permit
administrators to execute privileged commands to control the subset of
objects 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. When you use PowerShell to
create a session with Exchange Online, the session is by default remote
because you cannot connect to the servers running in Microsoft
datacenters in any other way. After it accepts the credentials you
provide in the connection request, PowerShell loads in the cmdlets you
are allowed to use through membership in RBAC role groups. The fact
that Exchange Online restricts the number of cmdlets available to
administrators when compared to on-premises deployments is immaterial.
Exactly the same mechanism populates your PowerShell session with
cmdlets whether you connect to an on-premises deployment or to a
cloud-based service.
Caution
Until
Microsoft removes the functionality, it is possible to use local
PowerShell with the Exchange 2013 snap-in to perform management
operations on a server. However, Microsoft is not testing local
PowerShell with Exchange anymore, and it is possible that problems will
appear in local PowerShell that will never be resolved. In addition,
running local PowerShell means that you bypass the controls otherwise
imposed by RBAC. Given the engineering and strategic focus on remote
PowerShell, it makes sense for everyone to make the transition now and
embrace this platform as the future of command-line Exchange management.
Connecting to remote PowerShell
To understand how remote PowerShell and RBAC work together,
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 enables him to create new mailboxes and
update the properties of existing mailboxes. Further, assume that the
user’s account is enabled to use remote PowerShell. In many cases,
people in specialist roles such as help desk personnel use EAC to
perform tasks, but an experienced Exchange administrator might prefer
to use a command-line interface because of its power and flexibility,
especially when processing multiple objects, when compared to EAC.
Figure 1
lays out the various components remote PowerShell uses 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 2013, 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 that reads data from Active
Directory. For the purpose of this discussion, assume that the account
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 –Identity AccountName –RemotePowerShellEnabled $True
All
PowerShell sessions flow through IIS because even a local connection
goes through localhost. All Exchange 2013 servers support IIS and the
PowerShell virtual directory, or vdir; 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 on which the Exchange management
components are 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 must specify the name of the server with which you want
to work. This is done by using the New-PSSession cmdlet, passing the
name of the server to which to connect in the https://fqdn/PowerShell/
form. 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.
When you
run EMS on a server on which the Exchange 2013 management components
are installed, the EMS initialization script creates an environment by
executing the code in the RemoteExchange.ps1 script (in the Exchange
binaries folder), which first attempts to create a remote session with
the local host. If successful, it then identifies your account to
Exchange, uses RBAC to determine the cmdlet set you are allowed to use,
and so on. The RemoteExchange.ps1 script is quite complex because it
has to handle the initiation of sessions in different circumstances, so
it’s easier to look at the code that connects a new session with
Exchange Online to see how the basic requirements to create a remote
PowerShell session are met. The following code defines the
Connect-ExchangeOnline function, which is suitable for inclusion in
your PowerShell profile (a document that initializes a session with
common commands and settings that you might want to use during the
session). In fact, this is how I connect to Exchange Online when I want
to manage my tenant domain. Three commands are executed:
Get-Credential gathers the name of the account with which to connect and its password.
New-PSSession establishes the remote PowerShell session with Exchange Online.
Import-PSSession imports the Exchange commands from the Exchange Online session into your current session.
function Connect-ExchangeOnline
{
$LiveCred = Get-Credential
$global:Session365 = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred
-Authentication Basic -AllowRedirection
Import-PSSession $global:Session365
}
IIS uses the RBAC mechanism
to check the user’s role and associated permissions through the
Exchange Authorization Library. 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 (referred to
as DC affinity). Many PowerShell cmdlets support the DomainController
parameter to enable you to connect to a specific domain controller
(specifying the fully qualified domain name [FQDN]) if the need arises.
Because
this user works with mailboxes as defined by the Recipient Management
role group, the set of cmdlets he can use includes commands with easily
identified purposes such as New-Mailbox, Set-Mailbox, Get-Mailbox, and
so on.
Tip
Permissions
granted through RBAC are evaluated during session initialization. If
you are assigned a new role, you have to create a new session with EMS
or EAC before you can access the cmdlets made available through the
newly assigned role.
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 such as setting properties on messaging connectors or performing
one-off operations such as creating a new Database Availability Group
(DAG) or mailbox database. Instead, RBAC makes sure that users can
access only the cmdlets they need to perform their jobs.
Limiting user functionality
When a new PowerShell session is created, you see no evidence
that your role has forced RBAC to restrict the cmdlet set or the
parameters you can use with cmdlets because the initialization of a
session progresses just as it would for a fully privileged user.
However, after you start to execute cmdlets, you quickly realize that
you can’t do as much as you’d like. For instance, if you log on with a
restricted user account and attempt to use the Get-Mailbox cmdlet to
fetch a list of mailboxes, all you’ll see is your own mailbox. This is
logical because your role allows you to see details of your own mailbox
but not others’. In the same way, if you then attempt to use the
Set-Mailbox cmdlet to update a property that only administrators can
access, you won’t be able to use even tab completion to reveal a
restricted property. However, unless the default role assignment policy
has been amended to block access to basic user options, you can use the
Set-Mailbox cmdlet to update properties that are generally exposed for
user update through Outlook Web App options, so (assuming JSmith is the
alias for your mailbox) you’ll be able to do things such as this:
Set-Mailbox -Identity JSmith –MailTip 'Hello World'
or this:
Set-Mailbox –Identity JSmith –Languages 'EN-US', 'EN-IE'
