PowerShell: the gift that keeps on giving to Exchange

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.

Discuss this Blog Entry 6

on Sep 22, 2011
@Murat, The examples that you have selected are not representative of the PowerShell commands that most Exchange administrators would need to use in day to day production. Routing any PowerShell through WMI is unnatural and only happens because a lot of Windows does not provide PowerShell modules to allow direct access. Thus, you have to route through WMI and experience the tortuous syntax that the mix and match of two very different languages demand. But you don't have to use WMI to manage Exchange 2007 or Exchange 2010 objects because these versions offer native PowerShell support. You only have to resort to WMI if you need to manage Exchange 2003 through the shell. And as Exchange 2003 was never designed to be managed through the shell, you end up with a mess. As Don Jones has pointed out, Microsoft recognizes that current PowerShell syntax can be cleaned up and they are doing this in PowerShell 3.0. Exchange will likely support PowerShell 3.0 in its next major release, so I think that's a good thing. Finally, commands changing as products evolve is something that has happened since the dawn of technology. The example you select is a very good illustration of how Microsoft is attempting to put order on PowerShell commands for Exchange. The Import-Mailbox and Export-Mailbox cmdlets had to be replaced because they depend on running Outlook on an Exchange server to be able to access PST contents. And while it's true that Microsoft could simply have updated the cmdlets with new code to call the provider used by New-MailboxExportRequest and New-MailboxImportRequest, they elected to change the name of the cmdlets to match those used for the other mailbox manipulation cmdlets processed by MRS running on the CAS. I don't see this as a bad thingl. Your assertion that New-MailboxImportRequest doesn't work "for most of the time" is laughable. The cmdlet works. Not all the time (old PSTs containing old items cause problems), but it does work.
on Sep 28, 2011
Have a look at the latest blog post by Don Jones where he explains that PowerShell is not a command line language. It resembles CLIs at times because that's how you invoke PowerShell via consoles such as EMS. However, the essential point here is that all Exchange management is built on top of PowerShell and that (to me at least) is a damn good reason to get to know it. Murat, insulting myself and Jeffrey Snover might make you feel happy but it really does you no good. If you stay embedded in ignorance I fear that your career will go nowhere. On the other hand, folks like Jeffrey Snover can look back on long and tremendously inventive careers where they made a huge difference to computing. You haven't, so enjoy your state of mind.
on Sep 22, 2011
sorry Tony, I didn't think "crazy" was rude but I know it is now. Tony, there is a GUI console, you are right. But you can do only trivial things with it. If you want some serious tasks you are allways routed to command shell. Command shell is cryptic. Look at the following commands from Don Jones: Get-Service | Where-Object -filterScript { $_.Status -eq 'Running' } Gsv | Where { $_.Status -eq 'Running' } get-wmiobject -class win32_networkadapterconfiguration | where-object { (get-wmiobject -class win32_networkadapter -filter "physicaladapter=true" | select -expand name) -contains $_.description } The first command lists the running services. The second one is PowerShell 3.o version of that command. Third command lists the physical network adapters. Don't take it wrong: Third command covers more than one line but it must be written on the same line. Don't you think they are cryptic? Besides this, commands change frequently. For example, Exchange 2007 had import-mailbox cmdlet but Exchange 2010 SP1 had new-mailboximportrequest. Do you know what? new-mailboximport cmdlet does not work for most of the times and it is well-known fact.
on Sep 22, 2011
Tony, I don't think PowerShell is a progress. And I have good reasons to think like that. First, we are Windows guys, not command line oriented Linux guys. We had been completing our tasks using GUI tools and it was just good. For us, real people in the trenches, the task is important and to complete a task as quickly as possible is more important. For these two reasons, GUI is good and sufficeintent.Up until this PowerShell mess. PowerShell is bad because it is not easy, intuitive, productive. For any non-trivial task you must refer to Google and make a search, learn a cmdlet and its cryptic usage. And after you used this cmdlet, you just forget it. Next time, you Google it again. Last year, I implemented the upgrade of the mail system for a big government office in my country. Switch was from Exchange 2003-2007 to 2010. I used dozens of PowerShell commands. None of them was in my mind and after the process none of them is in my mind either. It's shame because I'm an experienced systems engineer. And now, thousands of new cmdlets are coming. I think Snover is just crazy. And so you are.
on Sep 22, 2011
@Murat, Well, the Exchange developers give you both EMC and ECP if you want to work with a GUI. There are reasonably few instances where you have to use the shell. The point is that you can use EMS if you want to automate common tasks - and that there are tons of examples how to use EMS in productive ways. I'll be writing on this topic very soon. I also disagree that EMS is cryptic. The commands are named in a reasonably predictable fashion (gee, what is Set-Mailbox likely to do?) and once you learn the naming convention, you should have no difficulty mastering the shell. As to your comment about Jeffrey Snover, you're entitled to your opinion but you don't have to be rude. And as I type this, I wonder why I even bothered to respond to someone who obviously doesn't know how to be civil and restrained in their commentary. Have a nice day.
on Sep 22, 2011
First of all, the syntax examples that you've selected do not represent those that most Exchange administrators will use. I also disagree with the assertion that you have to resort to EMS on a frequent basis to do "serious work". Like any tool, you use EMS to do the work where the tool makes sense. For example, processing a set of mailboxes to generate a report of mailbox sizes. This has to be done in EMS because there isn't an option in the EMC or ECP GUIs. Routing any PowerShell commands through WMI will always require torturous code because WMI was never designed to be accessed by PowerShell. However, the only time that you need to use WMI with Exchange is to access Exchange 2003 objects as both Exchange 2007 and Exchange 2010 support PowerShell natively. As more and more Windows components support PowerShell, you'll have to use WMI less and less and that's a good thing. As Don points out, Microsoft understands that some PowerShell syntax could be clarified and streamlined. They plan to do this in PowerShell 3.0 and the next major release of Exchange will probably support PowerShell 3.0, so we get a gain there. You then comment about commands changing frequently. This has been the case with technology since the dawn of IT. In the case that you cite, the change is necessary for two reasons. First, to replace the need to install Outlook on Exchange mailbox servers. Second, to align the command names with the other mailbox manipulation tasks performed by the Mailbox Replication Service (MRS). There's logic here. And anyway, how hard is it to get up to speed with a few commands? Finally, your assertion that New-MailboxImportRequest doesn't work is just laughable. There are situations when PSTs that contain corrupt or very large items can't be imported but generally the cmdlet works as advertised. Certainly this has been my experience. So to make a leading statement with zero backup data is just plain silly.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.


Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro. His latest books are Office 365 for Exchange Professionals (eBook, May 2015) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×