This week, I was at the spring Microsoft Exchange Connections conference in Orlando, Florida. I presented three sessions: one about Exchange Server 2007 unified messaging (UM), one about continuous data protection (CDP) for Exchange, and one providing a gentle introduction to Windows PowerShell for Exchange administrators. This last session was my best-attended, and I had a lively crowd, so I thought I'd distill some of the things I talked about into a column to help spread the word to Exchange administrators about what they should know about PowerShell. My goal with both the session and this column is to reassure people who aren't scripters or programmers that they can learn and use this tool effectively. Most Exchange administrators have never had the need or the inclination to write scripts, partly because of how difficult it is to accomplish most meaningful tasks with the scripting tools available in Exchange Server 2003 and previous versions. PowerShell changes all that.
The analogy I used to explain how best to learn PowerShell is that of learning a foreign language. Let's take Spanish as an example. If you speak English, French, or Italian, learning the grammar rules for Spanish is pretty simple. After you've mastered those rules, the trick is to acquire a big enough vocabulary to communicate. A 10-word vocabulary is pretty useless; with a 100-word vocabulary, you can accomplish very simple tasks; with 500 or 1000 words, you can really get some stuff done. PowerShell is the same way: After you learn a few secrets, the rest is just building the right vocabulary.
The first big secret to losing your fear of PowerShell is to remember that you can use Exchange Management Shell in two ways. First, you can use it as an interactive environment to run one-off commands. In this mode, you can use it to do things that are too complicated or too slow to do as a series of steps in Exchange Management Console. Also, you can use it for the few tasks that aren't implemented in the Exchange Management Console GUI, although the need to do this will be dramatically reduced by the release of Exchange 2007 SP1. By using Exchange Management Shell in this mode, you can fairly quickly learn the commands you'll need frequently, such as cmdlet verbs (get, set, create, enable, and disable are a good starting set) and objects (Mailbox, User, DistributionGroupMember, and MailboxDatabase are the first ones I'd learn).
The second mode in which you can use Exchange Management Shell is as a full-blown scripting language, where you write scripts to accomplish tasks that require multiple steps. In this mode, you can use Exchange Management Shell to automate tasks you need to do often, or to provide a repeatable way to do things that are too complicated or dangerous to do manually each time.
In this second mode lies the second big PowerShell secret: Many useful Exchange Management Shell operations fall into a simple three-step pattern. First, get the set of objects you want to manipulate; second, filter or select the specific objects that you want to work with; and third, do something to them. (If you're familiar with the German language, you'll recognize the idea of having the verb at the end!) Let's take a simple example. Say you want to find all the files in a given directory that were modified on a specific day, then move only those files somewhere else. (This is a great way to roll over Microsoft IIS logs or other kinds of regularly generated files that you don't want to keep forever.) Here's one way to do it:
dir *.eml | where-object {$_.LastWriteTime -like "04/02 *"} | move-item -destination c:\oldSpam
The first part finds the set of files—in this case, all of the .eml files in the current directory. The second part selects only the files that were written on the given date. The third part moves the files to the specified location. Even if you don't recognize the specific PowerShell commands in this example, you can clearly recognize the intent of this snippet if you understand the three-step pattern.
Of course, there's a lot more to being productive with Exchange Management Shell than I can cover here, but the important thing I want to get across is that Exchange Management Shell is much more approachable than you probably think. You might not be a power scripter, but that's no reason to avoid Exchange Management Shell and PowerShell. After a brief, initial learning curve, you'll probably be surprised at what you can accomplish.
End of Article
Register
