Exchange makes extensive use of IIS. Client Access servers
use IIS for front-end services, such as authentication and proxying,
while Mailbox servers use IIS for back-end processing. On Client Access
servers, front-end apps for Outlook Web App, ECP, PowerShell, OAB, and
Autodiscover apps are configured on the Default Web Site. On Mailbox
servers, back-end apps for Outlook Web App, ECP, PowerShell, OAB, and
Autodiscover are configured on the Exchange Back End website.
1. Understanding remote execution in Exchange Admin Center
When you access Outlook Web App in a web browser, you are performing
remote operations via the PowerShell application running on the Web
server providing Exchange services whether you are logged on locally to
an Exchange server or working remotely. The same is true for ECP, but
the process is a little more complex, as shown in the following
high-level view of the login and workflow process:
-
Generally, Outlook Web App handles the initial login for ECP. Thus, when you access ECP using a URL such as https://mailserver17/ecp, the browser actually is redirected to Outlook Web App with a URL such as https://mailserver17/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fmailserver17%2fecp%2f.
-
Once you log on to Exchange, you are connected to the designated
Client Access server using the ECP app running on the Default Web Site.
-
ECP performs authentication checks that validate your access to the
Exchange 2013 server and determine the Exchange role groups and roles
your account is a member of. You must be a member of at least one
management role.
-
ECP creates a remote session with the Exchange 2013 server. A remote
session is a runspace that establishes a common working environment for
executing commands on remote computers.
-
The ECP app on the Client Access server acts as proxy for the ECP
app on the Mailbox server. By default, you are connected to the Mailbox
server on which your user mailbox resides.
-
As you perform tasks, these tasks are executed via the PowerShell app, which also has front-end and back-end components.
Important
Every step of the login and workflow process relies on properly
configured SSL certificates. HTTPS uses SSL certificates to establish
and encrypt connections. SSL certificates are also used to initialize
and validate remote sessions. Although you could disable the
requirement for HTTPS and allow HTTP to be used for connections, the
remote sessions themselves would still rely on properly configured SSL
certificates.
Thus, many interconnected components must be functioning correctly for you to connect to and work with Exchange Server.
2. Bypassing Exchange Admin Center and Exchange Management Shell
The Exchange Management Shell uses remote sessions that run via the
PowerShell application running on IIS. Because of this, you often need
a way to work directly with Exchange Server, especially when you are
trying to diagnose and resolve problems. Intuitively, you might think
that you should do this in the same way you establish a remote session
with Exchange Online. For example, if you want to connect to
MailServer18, you might want to use the following code:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange
-ConnectionUri https://mailserver18/powershell/ -Authentication Basic
-Credential wrstanek@pocket-consultant.com -AllowRedirection
Import-PSSession $Session
However, if there are any configuration problems, including issues
with SSL certificates, you won’t be able to connect to or work with
Exchange Server in this way. Instead, you’ll have to bypass the
web-based management interfaces and connect directly to an Exchange
server using the following technique:
-
Log on to the Client Access server or Mailbox server you want to
work with—either at the console or using a remote desktop connection.
-
Open an administrative PowerShell window by pressing and holding or
right-clicking Windows PowerShell and then tapping or clicking Run As
Administrator.
-
Import all Exchange-related snapins for Windows PowerShell by entering Add-PSSnapin *exchange*. You’ll then be able to work directly with Exchange and any related cmdlets.
Because Exchange has a two-tier architecture, you’ll often need to
perform troubleshooting tasks on both the front-end Client Access
servers and back-end Mailbox servers. Rather than log on locally to
each server, you may want to work remotely. You can invoke commands,
establish direct remote sessions, or execute commands remotely using
the -ComputerName parameter available with certain cmdlets.
To invoke commands on remote servers or establish a direct remote session, use the following technique:
-
Log on to any workstation or server where you’ve installed the
Exchange management tools. (Doing so ensures the Exchange related
snap-ins are available.)
-
Open an administrative PowerShell window by pressing and holding or
right-clicking Windows PowerShell, and then tapping or clicking Run As
Administrator.
-
Import all Exchange-related snapins for Windows PowerShell by entering Add-PSSnapin *exchange*.
-
Either
invoke commands on the remote Exchange server or establish a remote
session with the remote Exchange server. In your remote sessions, be
sure to connect directly, as shown in the following example:
$Session = New-PSSession -computername mailserver18
-Credential pocket-consulta\williams
Import-PSSession $Session
Important
When you work with Exchange in this way, you establish
connections via the Windows Remote Management (WinRM) service. On an
Exchange server, WinRM and related services are set up automatically.
