IT tutorials
Applications Server

Exchange Server 2013 : The Exchange Management Shell - Using remote Windows PowerShell - Connecting to remote PowerShell

12/1/2013 8:09:06 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

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.


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.


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:

The remote PowerShell architecture is based on a number of components, including an authorization library and an Active Directory driver that allow Exchange to understand what actions a user is allowed to perform when he connects to an Exchange server.

Figure 1. Remote PowerShell architecture

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 -Credential $LiveCred
-Authentication Basic -AllowRedirection
Import-PSSession $global:Session365

How the initialization script finds a server

When a user creates a remote PowerShell session on an Exchange server, the initialization script attempts to connect him to the same server. If the attempt to establish a connection with the local server fails, the initialization script then enumerates the full set of Exchange servers in the local site and attempts to make a connection to one of the servers chosen at random. If this attempt fails, the script moves on to the next server and continues until a successful connection is established or all available servers have been attempted and have failed. The initialization script works in the same way when executed on a workstation that has the Exchange management components installed on it, except that the initialization begins by randomly selecting one of the servers from the site.

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.


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'

Inside Out You can do some things; you can’t do others

Somewhat strangely, you’ll also be able to execute Get-MailboxStatistics to report the number of items in your mailbox but not Get-MailboxFolderStatistics to report on the folders and the items that each contains. This is all controlled by RBAC, the roles that your account holds, and the scope for the roles in terms of the cmdlets and parameters defined in each role. From this discussion, you should now understand how critical RBAC is to remote PowerShell and, by extension, to every aspect of the Exchange 2013 management toolset.

- Exchange Server 2013 : The Exchange Management Shell - How Exchange uses Windows PowerShell
- Active Directory Planning and Installation : Installing Active Directory - Promoting a Domain Controller
- Active Directory Planning and Installation : Understanding Domain and Forest Functionality
- Active Directory Planning and Installation : Verifying Network Connectivity - Tools and Techniques for Testing Network Configuration
- Active Directory Planning and Installation : Verifying the Filesystem - Setting Up the NTFS Partition
- Sharepoint 2013 : Building an Application with Access Services (part 6) - Adding a Macro, Reporting and External Data
- Sharepoint 2013 : Building an Application with Access Services (part 5) - Modifying Application Views, Creating a Query
- Sharepoint 2013 : Building an Application with Access Services (part 4) - Adding, Removing, and Editing Tables
- Sharepoint 2013 : Building an Application with Access Services (part 3) - Creating the Basic Application
- Sharepoint 2013 : Building an Application with Access Services (part 2) - Configuring SQL Server 2012, Configuring the Windows Development Environment Firewall
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Technology FAQ
- IIS Web site works in all browsers except Safari on Mac
- notification
- alternative current in to a pc
- parse url in JavaScript
- Dual WAN on a Fortigate 60
- Should Sys Admins (Domain Admins) also have user accounts?
- DR solution for data warehouse
- C# Creating Plugins
- SCCM 2007 collection by OU not showing all pc's
- Email account got spoofed?
programming4us programming4us