This is provided ‘AS IS’ with no warranties, and confers no rights. Use of included samples are subject to the terms specified at Microsoft
Do you have an Exchange 2010 infrastructure setup in your environment for your messaging needs? Do you want to manage your Exchange 2010 Servers from a Client PC or any other server? The most common answer to this question would be a ‘Yes’ followed by installing the Exchange Management Tools on the Client PC for example, a PC running Windows 7. No Brainer...isn't it?
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 Tools 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
<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
Thanks Manoj! awesome information, this also allows us to avoid users logging into Exchange Servers via Remote Desktop to perform routine jobs and save the actual RDS sessions :)