I love Windows PowerShell. It makes my job as a Microsoft Exchange Server administrator much easier by providing a powerful set of command-line tools that I can use to automate and customize my workflow. As other Microsoft products (such as the System Center line) integrate PowerShell, the management picture just keep getting better.
However, the original version of PowerShell we got with Exchange Server 2007 has some limitations. One of the biggest is that it doesn't support remoting: There's no good way to issue PowerShell—or, more properly, Exchange Management Shell (EMS)—commands to a remote machine. Sure, you can use Remote Desktop Protocol (RDP) to connect, and you can use Exchange Management Console (EMC) to manage Exchange servers from ordinary desktop workstations, but neither of those options are a replacement for the simple ability to run commands against a remote machine.
Exchange Server 2010 builds on two Windows components, a new version of PowerShell and the Windows Remote Management (WinRM) toolkit, to provide remoting capability. During the beta, the process of getting the correct builds of PowerShell and WinRM installed and configured has been rather challenging. Despite the challenge, the result is pretty sweet.
Remoting relies on the concept of PowerShell sessions. Think of such a session as a Telnet or Secure Shell (SSH) session: It encapsulates a single connection between the client and server, along with an environment, a set of commands, and a logon. You establish a session to a particular target computer by specifying its Uniform Resource Identifier (URI), then PowerShell makes the appropriate WinRM calls to connect to the remote computer, authenticate, and launch the new session. When the session is established, it's possible to load specific cmdlets (such as the EMS cmdlet set) into the remote session so that you can access them—by loading the Exchange cmdlets, you can use EMS to manage the target remotely.
This combination of technologies in Exchange 2010 essentially gives you the ability to remotely manage any Exchange organization for which you have credentials, from any machine that you can log on to. For example, my work laptop can manage my work Exchange organization or any of the lab environments I have set up at home or at work. This situation is much more versatile than Exchange 2007 offers. In fact, with a little care, I can write a script that I can run in each environment if I need to do something multiple times.
Anyone who needs to administer multiple Exchange organizations (hey, consultants, that means you!) or who wants full remote management access to their Exchange servers, can make immediate use of this feature when it ships with Exchange 2010. I look forward to seeing other product teams adopt the same model as they enhance their own PowerShell support.
Related Reading: