Today we have another guest blog post, this time by Bhargav Shukla.
Bhargav is passionate about many things, including Exchange and PowerShell, so I’ll allow him to introduce himself and afterwards we’ll get on with the post.
Bhargav Shukla is a Sr. Premier Field Engineer – Unified Communications with primary focus on Exchange Server platform.
Bhargav has been in IT since start of his career 14 years ago. Before joining Microsoft, he managed to work on almost any technology an IT consultant would be required to know. Active Directory, Exchange, RSA Security, VMware, Citrix, Cisco and so on. He also holds industry certifications such as Microsoft Certified Master – Exchange 2010, VMware Certified Professional, Citrix CCEA, RSA – CSE and Cisco CCNA/CCDA.
Bhargav has contributed to EHLO Blog as a guest blogger, Scripting Games 2011 as a Judge, Guest blogger on Hey, Scripting Guy! Blog. He also enjoys teaching Exchange Server in depth to MCM (Microsoft Certified Master) candidates.
When not working with customers, Bhargav tries to help scripters at The Official Scripting Guys Forum (http://social.technet.microsoft.com/Forums/en-US/ITCG/threads), leads Philadelphia Area Exchange Server User Group (www.phillyexug.org), shares his knowledge on his blog and twitter (blogs.technet.com/bshukla, http://www.twitter.com/bhargavs), plays chess and flies model airplanes.
Enough with the introductions, lets get on with the post. Welcome Bhargav and enjoy.
Recently I have been talking about Exchange Server 2010 and PowerShell and a consistent theme seems to be emerging. A few blog posts on internet also seem to contribute to the misconception that I am going to talk about.
The requirement for Exchange Server 2010 is PowerShell 2.0. When you connect to Exchange Server 2010 using Exchange Management Shell or from a client machine running PowerShell 2.0, it uses Windows Remote Management (WinRM) 2.0.
The requirement and use of WinRM 2.0 causes some confusion it seems.
When you connect to Exchange Server 2010 either using Exchange Management Shell (EMS) or using PowerShell 2.0 from a remote client machine, it uses WinRM features and creates a remote session to the Exchange server (even when EMS is launched from Exchange server it is connecting to).
If you have read about how to enable a computer to receive remote PowerShell connection requests, you may have come across articles like this one on MSDN which shows you that running “winrm quickconfig” will create a listener and allow you to connect remotely to the server in question using Powershell remoting.
Note that the article clearly states WinRM 2.0 will create listener on port 5985. When you connect remotely to Exchange Server 2010, you are connecting to “http://server fqdn/powershell”. You are not connecting to port 5985. You are not connecting to the listener created by WinRM. You are actually connecting to PowerShell virtual directory created by Exchange install and served by IIS.
If the server is built without any WinRM customizations and Exchange Server 2010 is running on it, there are no WinRM listeners configured. You can confirm this by running “winrm enumerate winrm/config/listener”. Even if server administrator has created a listener either manually or via GPO, the listener is still not used for EMS connection or remote PowerShell connection to Exchange Server configuration.
So if anyone tells you to run winrm quickconfig in order to be able to manage your Exchange Server 2010 environment remotely, you can debunk the myth with knowledge you now have!