Single Seat Administration of Exchange 2010 using PowerShell Implicit Remoting

  • Article

(Post courtesy Manoj Ravikumar Nair)

Do you have an Exchange 2010 infrastructure setup in your environment for your messaging needs? Do you want to manage your Exchange 2010 from a Client PC or any other server? The most common answer to this question would be a ‘YES’ followed by the installation of the Exchange Management Tools on the Client PC for example, a PC running Windows 7.

Hmm, now that would require you to install .NET framework 3.5.1 and IIS Web Management Tools as a prerequisite prior to installing the Exchange Management Tool (https://technet.microsoft.com/en-us/library/bb691354.aspx)

Also, for managing Exchange 2010, you need to install the Management Tool on a 64 Bit version of Windows Vista SP2 or Windows 7. That implies that you wouldn’t be able to manage your Exchange 2010 Infrastructure using 32 Bit Operating Systems.

If this is something that’s bothering you, well, PowerShell can be of great help here. Whether you are running a 32 Bit or a 64 Bit PC or Server, you can manage your Exchange 2010 Servers without installing the Management Tools using PowerShell 2.0.

Note that every Exchange 2010 Server role with the exception of the Edge Server Role leverages PowerShell Remoting. The Remote PowerShell is supported via HTTP to a virtual directory called PowerShell hosted on the Exchange Servers. This contains several modules that perform authentication checks and determines which cmdlets and parameters are assigned to the user invoking the connection. This happens both while running the Exchange Management Shell with the tools installed and when manually creating the remote connection

clip_image002

In this blog post, I will show you how to use the implicit remoting feature to manage your Exchange 2010 Servers.

Prerequisites

You need PowerShell version 2.0 installed on the Endpoint used to manage Exchange 2010 (It can be a Windows XP SP2, Windows Server 2003 SP2, Windows Vista or Windows 7, Windows 2008 or 2008 R2)

Windows 7 and Windows 2008 R2 have PowerShell version 2.0 preinstalled. For all other versions of Windows, you can download the Windows Management Framework from the link below:

https://support.microsoft.com/kb/968929

To verify the version of PowerShell, you can run the following cmdlet

 Get-Host

You also need to enable PowerShell Remoting on the Exchange Server. To enable PowerShell remoting, you can use the Enable-PSRemoting cmdlet or configure PowerShell remoting using Group Policies. If you are not familiar configuring PowerShell remoting using Group Policies, watch out for the future posts on this blog where I will cover the step by step procedure to configure PowerShell remoting using Group Policies.

clip_image004

Once you have met the prerequisites, you can start managing your Exchange 2010 infrastructure using the following steps.

Create a PowerShell session object and store it in a variable. In the example below, we are connecting to an Exchange Server (COLFAX.AlpineSkiHouse.com) using the –ConnectionUri parameter.

Now on the Workstation (in this example, I’m using a Windows 7 Enterprise x64 Edition, but this can be any machine running PowerShell version 2.0), you will create a session object as given below

 $session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri <fqdn of the Exchange Server>

clip_image006

Next, we will import the Session Object

 Import-PSSession $session

clip_image008

clip_image010

That’s all. You now have access to all the Exchange 2010 Cmdlets which can be used to manage your Exchange Servers

clip_image012

Now, if you want to provide alternative credentials, you can use the Get-Credential Cmdlet to store the credentials in a variable and supply it as a value to the –Credential parameter while using the New-PSSession Cmdlet

 $credential = Get-Credential

$session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri <fqdn of the Exchange Server> -Credential $credential

Exchange 2010 uses a new feature called Role Based Access Control (RBAC) which defines what administrators can do 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.

To learn more about PowerShell remoting, you can the refer extensive help documentation in the Shell window

 Get-Help about_remote