Manually configuring remote PowerShell connections
One of the major changes in Exchange 2010 is the toolset and its reliance on PowerShell remoting. When you double-click the Exchange Management Shell shortcut on a server or workstation with the Exchange Management Tools installed, you are connected to an Exchange server using a remote PowerShell session.
PowerShell remoting also allows you to remotely manage your Exchange servers from a workstation or a server even when the Exchange Management Tools are not installed. In this recipe, we'll create a manual remote shell connection to an Exchange server using a standard PowerShell console.
Getting ready
To complete the steps in this recipe, you'll need to log on to a workstation or a server and launch Windows PowerShell.
How to do it...
- First, create a credential object using the
Get-Credential
cmdlet. When running this command, you'll be prompted with a Windows authentication dialog box. Enter a username and password for an account that has administrative access to your Exchange organization. Make sure you enter your user name inDOMAIN\USERNAME
orUPN
format:$credential = Get-Credential
- Next, create a new session object and store it in a variable. In this example, the Exchange server we are connecting to is specified using the
-ConnectionUri
parameter. Replace the server FQDN in the following example with one of your own Exchange servers:$session = New-PSSession -ConfigurationName Microsoft.Exchange ` -ConnectionUri http://mail.contoso.com/PowerShell/ ` -Credential $credential
- Finally, import the session object:
Import-PSSession $session
- After you execute the preceding command, the Exchange Management Shell cmdlets will be imported into your current PowerShell session, as shown in the following screenshot:
How it works...
Every Exchange 2010 server role, with the exception of the Edge server role, utilizes PowerShell remoting. Each server runs IIS and supports remote PowerShell sessions via HTTP. Exchange Servers host a PowerShell virtual directory in IIS. This contains several modules that perform authentication checks and determine which cmdlets and parameters are assigned to the user making the connection. This happens both when running the Exchange Management Shell with the tools installed, and when creating a manual remote connection.
Remote PowerShell connections to Exchange 2010 servers use a special feature called implicit remoting that allows us to import remote commands into the local shell session. With this feature, we can use the Exchange PowerShell snap-in installed on the server in our local PowerShell session without installing the Exchange tools.
Note
You'll need to allow the execution of scripts in order to create a manual remote shell connection on a machine that does not have the Exchange tools installed. For more details, refer to the Creating and running scripts recipe in Chapter 1, PowerShell Key Concepts.
You may be curious as to why Exchange uses remote PowerShell even when the tools are installed and when running the shell from the server. There are a couple of reasons for this, but some of the main factors are permissions. The Exchange 2010 permissions model has been completely transformed in this latest version and uses a new feature called Role Based Access Control (RBAC) which defines what administrators can and cannot do. When you make a remote PowerShell connection to an Exchange 2010 server, the RBAC authorization module in IIS determines which cmdlets and parameters you have access to. Once this information is obtained, only the cmdlets and parameters that have been assigned to your account via an RBAC role are loaded into your PowerShell session using implicit remoting.
The Exchange 2010 Management Tools can only be installed on 64-bit systems and there are no 32-bit tools available. If you need the ability to manage Exchange from a 32-bit workstation, you can use a manual remote shell session to load the cmdlets into your local PowerShell session, as long as you have the Windows Management Framework Core installed.
There's more...
In the previous example, we explicitly set the credentials used to create the remote shell connection. This is optional and not required if the account you are currently logged on with has the appropriate Exchange permissions assigned. To create a remote shell session using your currently logged on credentials, use the following syntax to create the session object:
$session = New-PSSession -ConfigurationName Microsoft.Exchange ` -ConnectionUri http://mail.contoso.com/PowerShell/
Once again, import the session:
Import-PSSession $session
You can see here that the commands are almost identical to the previous example, except this time we've removed the -Credential
parameter and the assigned credential object. After this is done, you can simply import the session and the commands will be imported into your current session using implicit remoting.
Note
Although you can manually load the Exchange snap-in within a standard PowerShell console on a machine with the Exchange tools installed, this is not supported. You may also have mixed results when doing this, since this method bypasses remoting and, therefore, the RBAC system which may be required to give you the appropriate rights.
In addition to implicit remoting, Exchange 2010 servers running PowerShell v2 can also be managed using fan-out remoting. This is accomplished using the Invoke-Command
cmdlet and it allows you to execute a script block on multiple computers in parallel. For more details, run Get-Help Invoke-Command
and Get-Help about_remoting
.
You may also want to check out the Administrator's Guide to Windows PowerShell Remoting. It is a great resource that covers PowerShell remoting in depth and it can be downloaded from the following URL:
See also
- Using explicit credentials with PowerShell commands