The Joy of PowerShell for Exchange Administrators

My recent post outlining how important PowerShell is to Microsoft Exchange Server and how some of the concepts established in the implementation of Remote PowerShell in Exchange 2010 are finding their way into Windows Server 8 provoked a flurry of email messages, some of which posed the excellent question, “I’m struggling to master (or even understand) PowerShell; how do I make progress?”

Of course, such a question is impossible to answer, if only because the situations that we all find ourselves in vary so much. Those who are moving servers from Exchange 2003 to Exchange 2010 (or even Exchange 2007 or Office 365) are in a different place than those who already run Exchange 2007 or Exchange 2010 servers. Exchange 2003 doesn’t have a scripting language, so PowerShell is a real challenge for these administrators. I suspect that Exchange 2007 and Exchange 2010 administrators have at least opened up the Exchange Management Shell (EMS) and experimented with PowerShell, perhaps by running a few cmdlets to examine details of the Exchange configuration or by setting mailbox properties. This marks the high-water mark for many, who then escape back to the comfort of the GUI management environment provided by the Exchange Management Console (EMC).

The pity is that these folks might be missing the opportunity to mine the ever-increasing supply of wonderful PowerShell scripts and other snippets that populate the Internet. Exchange 2007 was released in late 2006, so there’s over five years worth of contributions from many talented people available free of charge to those who care to research, download, and test their work. Unlike a programming language such as C#, PowerShell scripts come ready to go. All of their secrets are exposed in the open and are available to be immediately turned to good use to improve how Exchange servers are managed by filling in the gaps that Microsoft has left in their tools. Although it’s true that some of the code written by those familiar with PowerShell will cause furrowed brows for newcomers, it’s also true that PowerShell is relatively easy to comprehend once you apply yourself.

For example, here’s a script posted by Exchang Server MVP Mike Pfeiffer on his blog. This script might look complex, but when you boil it down to its basics, the script accepts an input parameter of one or more Client Access Servers (CAS) and then interrogates those servers to discover the number of unique users who are currently connected to the servers via RPCs (for example, Outlook users) or HTTP (Outlook Web App).

function Get-CASActiveUsers {
[CmdletBinding()]
param(
      [Parameter(Position=0, ParameterSetName="Value", Mandatory=$true)]
      [String[]]$ComputerName,
      [Parameter(Position=0, ParameterSetName="Pipeline", ValueFromPipelineByPropertyName=$true, Mandatory=$true)]
      [String]$Name
)

process {
      switch($PsCmdlet.ParameterSetName) {
               "Value" {$servers = $ComputerName}
                "Pipeline" {$servers = $Name}
       }
      $servers | %{
           $RPC = Get-Counter "\MSExchange RpcClientAccess\User Count" -ComputerName $_
           $OWA = Get-Counter "\MSExchange OWA\Current Unique Users" -ComputerName $_
          New-Object PSObject -Property @{
          Server = $_
          "RPC Client Access" = $RPC.CounterSamples[0].CookedValue
           "Outlook Web App" = $OWA.CounterSamples[0].CookedValue
      }
    }
  }
}

This script is valuable because it allows you to figure out the load that a CAS is under before you remove it from production to perform maintenance such as applying a service pack or roll-up update. There’s no equivalent function in any of Microsoft’s management tools provided for Exchange so this is an example of how some relatively straightforward code can add real value. Best of all, it’s available free of charge and can easily be changed in whatever way you choose. And hopefully, if you improve the code, you’ll let Mike know and he can post the update on his blog. (You can also support Mike's work by buying a copy of his new Microsoft Exchange 2010 PowerShell Cookbook).  

Sometimes I even take my own advice (really!). Last weekend, I was helping a company to do some work to split off part of its IT infrastructure as a result of a corporate acquisition. The requirement arose to dump all of the membership of distribution groups before and after the event so that any unwanted entries in groups could be removed. Conceptually meeting this requirement seems simple enough: find all groups, expand group membership, dump to file. But groups can be nested and the task is more complex than it seems. A quick search turned up a script by Karl Mitschke to extract distribution group membership to an Excel file. After testing the script to ensure that it did what it claimed (always, but always, test scripts downloaded from the Internet), it didn't take long to wrap some code around the script to find all groups and create a unique file name for the output. Truly a great example of the usefulness of PowerShell in solving problems.

Still not convinced? Well, let’s take a look at the work of Pat Richard, another Exchange MVP, who recently posted an update to his New-PasswordReminder script. I think this script is great because it delivers real value out-of-the-box by scanning Active Directory for users whose passwords are soon to expire and then sends email to prompt the recipients to reset their password. There’s lots of good stuff to be mined from this script, including how to interrogate Active Directory with PowerShell, how to construct HTML format text, and how to create and send messages. I can easily imagine how these “chunks” of functionality could be repurposed.

Finally, we should acknowledge that Microsoft includes a number of very nice scripts in the Exchange kit. My personal favorite is ReDistributeActiveDatabases.ps1, which you can find in the scripts directory (the default location is C:\Program Files\Microsoft\Exchange\V14\Scripts) on any Exchange 2010 SP1 server. ReDistributeActiveDatabases is designed to move databases around within servers in a Database Availability Group (DAG) so that the active copy of each database is running on its preferred server. The idea is that, over time, database transitions will cause databases to end up on servers that might not be the best (for example, one server will host more active databases than it should) and that running this script will restore order to the situation. A good overview of how to run the script can be found in a post by Paul Cunningham. Again, you can amend the script to serve your own purpose if you think that it’s missing a feature. After all, the code is just PowerShell and can be edited with any text editor, including NotePad.

PowerShell might seem complex at the start, and there’s certainly hundreds of Exchange cmdlets to get to know over time (Exchange 2010 SP1 includes over six hundred). However, the joy of PowerShell is in the ability to discover, repurpose, and triumph with code that you or others write. That code can be anything from a one-liner to the type of scripts discussed here. And while you might conclude that you don’t need any of this because you’re heading to use Exchange Online in Office 365, you’ll soon discover that PowerShell offers lots of power and flexibility to Office 365 administrators, if you but care to use it.

By the way, if you're inspired to look for some books to learn about PowerShell, I previously posted my list of recommended PowerShell reading to get you started.

Discuss this Blog Entry 7

MR
on Oct 3, 2011
The JOY? While I do see that many new options become available with Powershell I do not agree that it's a "simple" replacement for the former GUI consoles. Your argument that all it takes is a little learning isn't exactly true. If you are to be proficient at it then you need to know the scripting language. To be fair we all should have at least some background in how script work but even if you do, there are still many commands, objects, arguments, etc. that are specific to Exchange. In other words, a lot to learn. Saying that you can find someone elses examples to use is a cop out on MS part. What are they pretending to be - open source? I've had more than one simple management issue that resulted in a great deal of time doing research to get it entered just right when the MS example didn't work. It isn't rocket science or even having to learn a complete programming language but to say it's simple to learn is absolute BS. Really I think MS went too far in removing some basic day to day operational controls from the GUI. Your example is supposed to show how easy it is to use PS instead but I say it proves just the opposite. While it may be nice in some environments to have the ability to do what you are describing, the script you give certainly isn't short and simple compared to what could take about 5 mouse clicks in a GUI and is a basic need for an admin. By all means, keep Powershell, it does add some great access to the server but quit gutting the GUI. I can only assume MS is either too lazy to program the GUI or they are trying to push the part time admin into succumbing to cloud based managed services.
on Sep 30, 2011
Since Powershell is a object orientated language, there is no reason for it not to have a GUI.
MR
on Oct 3, 2011
The JOY? While I do see that many new options become available with Powershell I do not agree that it's a "simple" replacement for the former GUI consoles. Your argument that all it takes is a little learning isn't exactly true. If you are to be proficient at it then you need to know the scripting language. To be fair we all should have at least some background in how script work but even if you do, there are still many commands, objects, arguments, etc. that are specific to Exchange. In other words, a lot to learn. Saying that you can find someone elses examples to use is a cop out on MS part. What are they pretending to be - open source? I've had more than one simple management issue that resulted in a great deal of time doing research to get it entered just right when the MS example didn't work. It isn't rocket science or even having to learn a complete programming language but to say it's simple to learn is absolute BS. Really I think MS went too far in removing some basic day to day operational controls from the GUI. Your example is supposed to show how easy it is to use PS instead but I say it proves just the opposite. While it may be nice in some environments to have the ability to do what you are describing, the script you give certainly isn't short and simple compared to what could take about 5 mouse clicks in a GUI and is a basic need for an admin. By all means, keep Powershell, it does add some great access to the server but quit gutting the GUI. I can only assume MS is either too lazy to program the GUI or they are trying to push the part time admin into succumbing to cloud based managed services.
on Oct 25, 2011
While the Exchange Powershell is clearly powerful, so is C, Java and Assembly. Doesn't mean I want to change careers to a developer. heres to hoping MS gives us a few more GUI options...
on Sep 28, 2011
Tony, yes I have a problem with PowerShell. It is a quantum leap in the wrong direction. I like command line indeed but not PowerShell. Command line commands must be short, easy to understand and easy to remember, easy to implement. Power is not short; typical commands covers a line, frequently more than one line. They are not easy to understand and remember. They are not easy to implement either. Almost generally, you must search, to find the proper command first and then to learn the syntax. I think PowerShell has no future. So, I may attend your PowerShell courses, with pleasure. Just if I am to be paid!
on Sep 27, 2011
Tony, you must be surely joking when you say "Theres no equivalent function in any of Microsofts management tools provided for Exchange so this is an example of how some relatively straightforward code can add real value. " The scripts seems to take the info from the performance counters and you can observe these numbers using the built in Performance Monitor console. I checked and saw that the counters are MSExchange OWA\Current Unique Users and MSExchange RPCClientAccess\Active User Count. So, There IS an equivalent console that gives the info this cryptic script delivers.
on Sep 28, 2011
You're correct that you can use Performance Monitor to view the counters but that wasn't the point I was making. There is no equivalent feature in EMC or ECP (Microsoft's management tools for Exchange; performance monitor is a general purpose tool for Windows). The point here is that you can use PowerShell to extract and report information relatively easily about some interesting data concerning Exchange servers. Furthermore, if you don't want to write the code, there's a fair chance that someone else will have done it for you. Murat, you really seem to have a problem around PowerShell. Maybe you should come to an Exchange 2010 Maestro training event so that Paul Robichaux and I can help you understand its true value for Exchange administrators? TR

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.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro and the author of Microsoft Exchange Server 2010 Inside Out (Microsoft Press) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×