Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2011-04-28

The Exchange Management Shell, built on Windows PowerShell technology, provides a powerful command-line interface for Microsoft Exchange Server 2010 that enables automation of administrative tasks. With the Shell, you can manage every aspect of Exchange. You can enable new e-mail accounts, configure SMTP connectors, store database properties, store transport agents, and more. The Shell can perform every task that can be performed by the Exchange Management Console and the Exchange Web interface in addition to tasks that can't be performed in those interfaces. In fact, when a task is performed in the console and the Web interface, those interfaces use the Shell to perform the task.

The Shell also provides a robust and flexible scripting platform that can reduce the complexity of current Microsoft Visual Basic scripts. Tasks that previously required many lines in Visual Basic scripts can now be done by using as little as one line of code in the Shell. The Shell provides this flexibility because it doesn't use text as the basis for interaction with the system, but uses an object model based on the Microsoft .NET platform. This object model enables the Shell cmdlets to apply the output from one command to subsequent commands when they are run.

If you want to start using the Shell immediately, see Exchange Management Shell Basics. Otherwise, read this topic for more information about the Shell in Exchange 2010.

Local Shell and Remote Shell

The Shell in Exchange 2010 uses two methods, local Shell and remote Shell, to connect to servers running Exchange 2010. The following sections describe each of the concepts.

Local Shell

In Microsoft Exchange Server 2007, the Shell consists of a Windows PowerShell host; a Windows PowerShell snap-in, which contains all of the Exchange cmdlets; and some additional custom scripts. Loading all three components enables you to run Exchange cmdlets on the Exchange server you opened the Shell on.

When you open Windows PowerShell on a computer, you create a local session. In simple terms, a session is an environment in which Windows PowerShell runs. Cmdlets, variables, and other Windows PowerShell components within the same session can share data with each other. In Exchange 2007, cmdlets are always run in the local session on the local Exchange 2007 server. Even if you change an object that resides on a different server, the cmdlet is always run on the local Exchange server.

Except for the Edge Transport server role, Exchange 2010 doesn't use the local Shell. Instead, it uses a new concept called remote Shell, which is explained in the next section.

Remote Shell

With Exchange 2010, you can connect to a remote session on a remote Exchange 2010 computer to perform commands on that remote computer. Whether you use the Shell to administer a server you are physically connected to or administer a server across the country, remote Shell is used to perform the operation in Exchange 2010. Only the Edge Transport server role doesn't use remote Shell.

Remote Shell performs almost like the Shell in Exchange 2007. Other than feature changes that occurred between versions, you're likely to continue using the Shell as you did in Exchange 2007. If the Exchange management tools are installed and you want to use the Shell, follow the procedure in the Open the Shell topic.

In Exchange 2010, when you click the Shell shortcut, Windows PowerShell opens. Unlike in Exchange 2007, a Windows PowerShell snap-in for Exchange isn't loaded. Instead, Windows PowerShell connects to the closest Exchange 2010 server using a new required component called Windows Remote Management 2.0, performs authentication checks, and then creates a remote session for you to use. When the remote session is created, you're given access only to the cmdlets and the parameters associated with the management roles you've been assigned. For more information about management roles, see Understanding Role Based Access Control.

A benefit of remote Shell is that you don't need to install Exchange-specific tools on your computer. With just Windows PowerShell and Windows Remote Management installed on any client computer running the Windows Vista operating system with Service Pack 1 (SP1) or Windows Server 2008, you can connect to a remote Exchange 2010 computer to administer it. However, while it's possible to manage an Exchange 2010 server with just Windows PowerShell and Windows Remote Management, we recommend that you install the Exchange management tools on any computer that you use to manage Exchange 2010. Without the Exchange management tools installed, you need to connect to the remote Exchange 2010 server manually, and you don't have access to the additional capabilities that the Exchange management tools provide.

For more information about connecting to Exchange 2010 servers without the Exchange management tools installed, see Create a Manual Remote Shell Connection.

Edge Transport Server Role

Exchange 2010 uses the local Shell only on the Edge Transport server role. This is because each computer that runs the Edge Transport server role is administered individually and because the Edge Transport server role doesn't use Active Directory Domain Services (AD DS). You can open the Shell on an Edge Transport server using the procedure in Open the Shell.