When reading the list of speakers for the Fall 2011 Exchange Connections conference, I was impressed to see Jeffrey Snover on the list of speakers who will deliver a keynote session. For those who are unfamiliar with his name, Jeffrey is the father of PowerShell and is therefore someone who has made a huge and important contribution to Exchange, albeit indirectly. His keynote should be worth the admission price alone.
I realize that many of you who work with Exchange might not share my enthusiasm for PowerShell. After all, isn’t it just revisiting the command-line past, something that makes one think that you’re coping with the piping and scripting beloved of UNIX and Linux geeks? Well, the command-line nature of PowerShell is there for all to see and PowerShell is awfully fond of piping (and gets a lot of its power from this ability) and there’s no doubt that scripting is something that PowerShell devotees spend a lot of their time discussing, but all of this is missing the point. The reason why I think PowerShell has made such a contribution to Exchange, including Exchange Online in Office 365, is simple: it provides the ability to automate common administrative tasks quickly, simply, and accurately in a way that even the best-designed GUI-based management console will never be able to do.
The Exchange development group took the momentous decision from Exchange 2007 onwards to encapsulate the business logic that drives the product around what is now a very large set of well over 600 PowerShell cmdlets. In passing, let me say that “cmdlet” is one of my least favorite technical terms. I find it to be neither fish nor foul and would much prefer the simplicity of “command” instead. However, cmdlet is the term coined by the PowerShell developers and who am I to debate the wisdom of their choice?
Moving away from my bias against cmdlet (only the term, not the implementation), the decision taken for Exchange 2007 allowed the developers to build all of the Exchange administrative interfaces on a common foundation, meaning that the Exchange Management Console (EMC), the Setup program, and the Exchange Management Shell (EMS) all execute the same code. This eliminated the inconsistency seen in previous versions of Exchange and allowed Microsoft to remove much redundant and overlapping code.
The central role of PowerShell was further expanded in Exchange 2010 with the addition of the Exchange Control Panel (ECP), which leverages the same platform as EMC and EMS. Exchange 2010 also ties its Role-Based Access Control (RBAC) mechanism to the array of PowerShell cmdlets, defining roles in terms of the cmdlets that a holder of a role can execute. Indeed, the granularity is such that RBAC allows roles to be defined to the level of the parameters to a cmdlet that a user can execute, meaning that users can retrieve details of their mailboxes (running the Get-Mailbox cmdlet behind the scenes) and set some properties (with Set-Mailbox) while administrators can do a lot more.
Exchange 2010 also adds Remote PowerShell, allowing administrators to run PowerShell to manage remote Exchange servers from workstations and other computers. Remote PowerShell forces users to connect via IIS and be authenticated to build a session that connects to Exchange. The session includes details of all of the cmdlets and parameters that the user is entitled to use as defined by the RBAC roles that they hold. Collectively, these components provide the ability to connect to Exchange Online running in Office 365 to perform management using EMC, ECP, or EMS (see this blog if you need details about how to connect to Office 365 with a Remote PowerShell session). Indeed, as explained in an excellent blog it's even possible to emulate the connections used to connect with PowerShell to manage Office 365 by establishing external connections from the Internet to manage on-premises Exchange 2010 servers (protected of course by a reverse proxy).
There's no doubt that the move to embrace PowerShell so comprehensively was a stunning and far-reaching decision that no other major Microsoft server product emulated for several years. Indeed, it’s only relatively recently that elements of Windows Server such as Active Directory have supported similar access via PowerShell (the TechNet articles on the topic are dated from February 2009). Perhaps the big break-through will occur in Windows 8 as Windows Server 8's GUI-based management console is built on top of PowerShell (see the articles by Paul Thurrott and Don Jones for more details). The most important points are that Windows Server 8 contains hundreds of new cmdlets to enable management of components from the shell and to eliminate the need for administrators to use GUI consoles. In short, Windows administrators need to get rid of the idea of logging on to a server to do work, something that Exchange administrators have become used to since the advent of Remote PowerShell support in Exchange 2010.
In addition, the developer preview of Windows Server 8 that was recently released includes PowerShell Web Access, another component of PowerShell 3.0 (this MVP blog gives a good write-up on the topic). To me, PowerShell Web Access looks very much like a natural development from the ideas proven by Exchange 2010's implementation of Remote PowerShell where servers are managed from workstations through PowerShell without the need to log-on directly to the target server. The interaction between workstation and target server is managed by a combination of IIS, Active Directory, and Exchange's Role-Based Access Control (RBAC) security model.
All in all, PowerShell provides Exchange administrators with huge potential for managing their servers in a way that EMC or ECP just can’t deliver (in passing, let me also acknowledge the wisdom of whoever decided to include the function into EMC that outputs the PowerShell code for the different operations performed through the console; this is a fantastic learning device for anyone who wants to understand the basic syntax and construct for using PowerShell to manage Exchange). If you haven’t yet taken the plunge to get down and dirty with PowerShell you’re really missing out on something that can save you scads of time. And if you manage to get to Exchange Connections in Las Vegas, maybe you’d come by and say hello to Jeffrey Snover and thank him for the contribution that he and the PowerShell team have made to make the life of administrators so much easier.
