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.

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.