If Exchange admins aren't already familiar with PowerShell, they need to take the steps to familiarize themselves...
with it. Starting from scratch may be one approach, but when learning PowerShell scripting, many admins first work with it by using or even tailoring a PowerShell script someone else developed to perform a certain task.
Exchange fellow Michael van Horenbeeck (MVP/MCM) highlighted some Exchange Server tools that should be part of the Exchange admin tool set. Not surprisingly, PowerShell scripts from the Exchange community are part of this set. It's good to look at these scripts when you're learning PowerShell because there is a high demand for the functionality they offer, functionality the product itself does not offer or that does not work well with product functionality. Another reason is that some of these scripts simplify an otherwise tedious or repetitive task.
The intended use for these scripts more or less depends on the author. Many authors take the time to make scripts generic by parameterizing the script, for example. This allows for calling the script and specifying factors on the command line -- such as server names or mailbox database names -- when calling the script instead of having to edit the source code.
Proper error handling should also be part of generic-purpose scripts, allowing the script to deal with exceptions; these exceptions could include when a server is not responding or an IP address is not properly specified. How the exception is handled is up to the author. But again, adding these elements may substantially increase the script size, may require a decent amount of time and may require testing, so you may not see these elements everywhere.
The beautiful thing is that when the author takes the time to parameterize the script and add header information, PowerShell lets you explore script usage just like with regular cmdlets. Look, for example, at the Goodman Exchange environment reporting script from Van Horenbeeck's tip. Let's assume you downloaded the script to a local folder on your Exchange Server and you set the Execution Policy to unrestricted using Set‑ExecutionPolicy Unrestricted, as the script isn't signed. This script allows you to enter the script's name followed by a dash, after which you can tab your way through the available parameters relevant to the current parameter set, just like with cmdlets. Parameter sets are available parameters that depend on other specified parameters.
The provided header information also allows you to call Get-Help with the script name to get a description of the usage. You can also add –examples to get calling examples or –detailed to get information on the parameters to use (Figure 1).
Put this in contrast with some of the more basic scripts (no offense). This is also different from scripts developed in the early days of PowerShell that require you to dive in to configure variables, such as a server name or SMTP host, that require user input at execution time. While these scripts may work and do a fine job in certain scenarios, they can be a lot harder to maintain or to make part of a tool set; you're more or less required to dive in and sometimes to understand what's going on before you can tailor it.
Then again, from a learning perspective, having to dive in and get your hands dirty as you try to familiarize yourself with a script is not necessarily a bad thing. So go ahead -- get your hands dirty, open up a script and try to understand.
Some of the biggest resources for learning PowerShell scripting are the Microsoft-operated TechNet Gallery and the community-driven PowerShell Code Repository. These are great for learning by example as well as great for checking if somebody has already created a script for a certain task.
One warning though: Always run scripts in a controlled lab, non-production environment first. While PowerShell may be a powerful environment to accomplish things simply and easily, it may also break things just as quickly.
About the author:
Michel de Rooij is a consultant and Exchange MVP from the Netherlands. Michel started originally as a developer back in 1994 but quickly switched to infrastructure-related projects and started focusing on Exchange in 2004, covering a number of areas, including migrations, transitions, consolidation and disentanglement. Besides Exchange, Michel's other areas of interest are PowerShell, Active Directory, Lync and messaging in general. Michel is a contributor to The UC Architects podcast theucarchitects.com and blogs about Exchange and related subjects at eightwone.com.