Microsoft Exchange Server PowerShell Cookbook(Third Edition)
上QQ阅读APP看书,第一时间看更新

Manually configuring remote PowerShell connections

Just like Exchange 2010, Exchange 2013 is very reliable on remote PowerShell for both on-premises and cloud services. When you double-click on 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 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...

Let's see how to manually configure remote PowerShell connections, using the following steps:

  1. 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 an administrative access to your Exchange organization. Make sure that you enter your user name in the DOMAIN\USERNAME or UPN format:
    $credential = Get-Credential
    
  2. Next, create a new session object and store it in a variable. In this example, the Exchange server that 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://tlex01.testlabs.se/PowerShell/ ` -Credential $credential
    
  3. Finally, import the session object:
    Import-PSSession $session
    
  4. 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 to do it...

How it works...

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 that make the connection. This happens when running both the Exchange Management Shell with the tools installed and when creating a manual remote connection. The IIS virtual directory that is used to connect is shown in the following screenshot:

How it works...

The IIS virtual directories can also be retrieved using PowerShell with the Get-WebVirtualDirectory cmdlet, and to get the information on the web applications, use the Get-WebApplication cmdlet.

Remote PowerShell connections to Exchange 2013 servers use the same special feature as Exchange 2010 did, 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.

Tip

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 Understanding the new execution policy recipe in Chapter 1, PowerShell Key Concepts.

You may be curious to know 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 and 2013 permissions model have been completely transformed in this latest version and use 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 2013 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.

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://tlex01.testlabs.se/PowerShell/

Once again, import the session:

Import-PSSession $session

When the tasks have been completed, remove the session:

Remove-PSSession $session

Here, you can see that the commands are almost identical to the previous example, except that this time, we removed the -Credential parameter and used 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.

Tip

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 may be required to give you the appropriate rights.

In addition to implicit remoting, Exchange 2013 servers running PowerShell v3 or above 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.

Connecting to the Exchange online is more common, and it's very similar to connecting to a remote PowerShell on-premises. The following prerequisites are required: .NET Framework 4.5 or 4.5.1, and then either Windows Management Framework 3.0 or 4.0.

We will now create a variable of the credentials by running the following command:

$UserCredential = Get-Credential

We then create a session variable as follows:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange ` -ConnectionUri https://outlook.office365.com/powershell-liveid/ ` -Credential $UserCredential -Authentication Basic ` -AllowRedirection

Finally, we import the session:

Import-PSSession $Session

You can then perform the tasks you want to do by running the following command:

Get-Mailbox

When the tasks have been completed, remove the session:

Remove-PSSession $session

You may also want to check out the Administrator's Guide to Windows PowerShell Remoting. Even though this is intended for PowerShell Version 2, it still applies to newer versions. It is a great resource that covers PowerShell remoting in depth, and it can be downloaded from http://powershell.com/cs/media/p/4908.aspx.

See also

  • Using explicit credentials with PowerShell commands