The graphical tools provide just about everything you need
to work with Exchange organizations. Still, there are many times when
you might want to work from the command line, especially if you want to
automate installation, administration, or maintenance with scripts. To
help with all your command-line needs, Exchange Server includes
Exchange Management Shell.
Exchange Management Shell is an extension shell for Windows
PowerShell that includes a wide array of built-in commands for working
with Exchange Server. Windows PowerShell commands are referred to as
cmdlets (pronounced commandlets)
to differentiate these commands from less powerful commands built into
the command prompt and from more full-featured utility programs that
can be invoked at the command prompt.
Note
For ease of reading and reference, I’ll usually refer to command
prompt commands, command shell cmdlets, and command-line invoked
utilities simply as commands.
On any computer where you’ve installed the Exchange management
tools, you’ll be able to access Exchange Management Shell from Start.
With Windows Server 2008 R2, select Start, choose All Programs, and
then use the Microsoft Exchange Server 2013 menu. With Windows Server
2012 RTM or R2, you’ll find an Exchange Management Shell tile on the
Start screen. Whether you are working with the Start menu or the Start
screen, you can pin Exchange Management Shell to the desktop taskbar by
pressing and holding or right-clicking the related icon and then
selecting Pin To Taskbar. Exchange Management Shell is shown in Figure 1.
Real World
Exchange
Admin Center is a web-based management console that runs as an
application on your Client Access servers. When you install the Client
Access server role for Exchange 2013, the server is configured
automatically with a Windows PowerShell gateway that acts as a proxy
service. This proxy service allows you to run remote commands in web
browsers and in remote sessions. Whenever you work with Exchange Admin
Center or Exchange Management Shell, the commands are executed via this
proxy—even if you log on locally. Thus, every time you work with
Exchange Server, you are using a remote session.
When you log in to Exchange Admin Center, you are using the Default
Web Site running on Internet Information Services (IIS) which processes
your actions. Every command you perform in Exchange Admin Center is
remotely executed via the Windows PowerShell gateway, as is any command
you perform in Exchange Management Shell. Any task you can perform in
Exchange Admin Center can be performed in Exchange Management Shell.
The basics of working with Exchange Management Shell are straightforward:
-
Type get-command to get a full list of all available cmdlets on the server.
-
Type get-excommand to get a full list of all Exchange-specific cmdlets available.
-
Type help cmdletName
to get help information, where cmdletName is the name of the command you are looking up.
-
Type Update-ExchangeHelp to update the help files for Exchange-specific cmdlets (CU2 or later only).
Important
When you are working with Exchange Management Shell, the default
recipient scope is set the same as your logon domain. If you are in a
multi-domain environment and want to work with recipients throughout
the Active Directory forest, make sure the Shell session has
ViewEntireForest enabled. Enter Get-ADServerSettings to view the current Active Directory Server settings. Enter Set-ADServerSettings -ViewEntireForest $true to set the recipient scope to the entire forest.
Whenever you remotely
manage Exchange services using Powershell, you are relying on the
Windows PowerShell remoting features. These features are supported by
the WS-Management protocol and the Windows Remote Management (WinRM)
service that implements WS-Management in Windows.
Windows Management Framework includes Windows PowerShell and WinRM.
Computers running Windows 8 and later, as well as Windows Server 2012
and later, include Windows Management Framework 3.0 or later. You must
install Windows Management Framework on computers running Windows 7 SP1
or later, as well as computers running Windows Server 2008 R2 SP1 or
later. You can download the framework from http://go.microsoft.com/fwlink/p/?LinkId=272757.
With Windows Server 2012 RTM or R2, you can verify the availability
of WinRM services and configure Windows PowerShell for remoting by
following these steps:
-
Type PowerShell
in the Apps Search box. To start Windows PowerShell as an administrator
press and hold or right-click the Windows PowerShell shortcut and
select Run As Administrator.
-
The WinRM service is configured for manual startup by default. You
must change the startup type to Automatic and start the service on each
computer you want to work with. At the PowerShell prompt, you can
verify that the WinRM service is running by using the following command:
get-service winrm
As shown in the following example, the value of the Status property in the output should be Running:
Status Name DisplayName
------ ---- -----------
Running WinRM Windows Remote Management
If the service is stopped, enter the following command to start the
service and configure it to start automatically in the future:
set-service –name winrm –startuptype automatic –status running
-
To configure Windows PowerShell for remoting, type the following command:
Enable-PSRemoting –force
Exchange 2013 is designed to be remotely managed from domain-joined
computers. If your computer is connected to a public network, you need
to disconnect from the public network, connect to a domain, and then
repeat this step. If one or more of your computer’s connections has the
Public connection type, but you are actually connected to a domain
network, you need to change the network connection type in Network And
Sharing Center and then repeat this step.
In many cases, you will be able to work with remote computers in
other domains. However, if the remote computer is not in a trusted
domain, the remote computer might not be able to authenticate your
credentials. To enable authentication, you need to add the remote
computer to the list of trusted hosts for the local computer in WinRM.
To do so, type the following:
winrm s winrm/config/client '@{TrustedHosts="RemoteComputer"}'
where RemoteComputer is the name of the remote computer, such as:
winrm s winrm/config/client '@{TrustedHosts="MailServer12"}'
If you cannot connect to a remote host, verify that the service on
the remote host is running and is accepting requests by running the
following command on the remote host:
winrm quickconfig
This command analyzes and configures the WinRM service. If the WinRM
service is set up correctly, you’ll see output similar to the following:
WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine
If the WinRM service is not set up correctly, you’ll see errors and
need to respond affirmatively to several prompts that allow you to
automatically configure remote management. When this process completes,
WinRM should be set up correctly.
Whenever you use Windows PowerShell remoting features, you
must start Windows PowerShell as an administrator by pressing and
holding or right-clicking the Windows PowerShell shortcut and selecting
Run As Administrator. When starting Windows PowerShell from another
program, such as the command prompt (cmd.exe), you must start that
program as an administrator.
