(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 (http://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
In this blog post, I will show you how to use the implicit remoting feature to manage your Exchange 2010 Servers.
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:
To verify the version of PowerShell, you can run the following cmdlet
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.
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>
Next, we will import the Session Object
That’s all. You now have access to all the Exchange 2010 Cmdlets which can be used to manage your Exchange Servers
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
Enabling remoting isn't required if you strictly want to manage Exchange using remote powershell since it uses /powershell vDir and not remoting you enabled in your steps outlined in this article. Enable remoting only if you want to also manage OS or run other Powershell cmdlets that doesn't necvessarily manage Exchange (i.e. get-process).
Don't believe me? Try this: for an Exchange server where remoting isn't enabled yet, run the new-pssession and import-pssession cmdlets from management machine running PowerShell 2.0. You will be able to connect to Microsoft.Exchange configuration context. You however won't be able to Invoke-Command against that server until you enable psremoting as you explained.
This is general misconception that enable-psremoting is a pre-requisite to managing Exchange 2010 using remote PowerShell. It's not. It is required only to manage anything on that server outside of Microsoft.Exchange configuration context.