PowerShell basics for the Exchange admin

Creating PowerShell scripts in Exchange can help you avoid typing out long EMS commands for daily administrative actions. Here are the basics.

If you've done any work with Exchange Management Shell commands, you know that many of them can be lengthy and...

complex -- especially when you pipe multiple commands together. Since certain administrative tasks in Exchange Server 2007 and Exchange 2010 must be performed from the command line, familiarity with EMS cmdlets isn't optional.

Having to type long and complex commands isn't always a good use of your time. If, for example, there's a specific administrative action that you perform regularly, it's a waste of time to manually issue the same command every time you need to perform the action. Additionally, certain administrative tasks can be destructive if performed incorrectly. Manually coding long commands can greatly increase your chances for making a mistake. In these situations, it's better to create a PowerShell script.

Historically, scripting has earned a bad reputation among admins. But PowerShell scripts deserve a second chance. Since a PowerShell script is simply a text file that contains one or more PowerShell commands, writing one is as easy as issuing individual PowerShell commands.

For example, let's create a simple PowerShell script by adapting the following command into a script:

Get-Mailbox | Format-Table Name, ServerName

This command retrieves a list of all Exchange mailboxes in the organization. The results are piped into the Format-Table command, which instructs Exchange to create a table displaying the name of each mailbox and the name of the server hosting each mailbox. To convert this into a script, let's break it into two separate commands. The break will occur at the pipe symbol:

Get-Mailbox |
Format-Table Name, ServerName

To turn these commands into a script, save them to a file by typing the commands into Microsoft Notepad and then saving the document with a .ps1 extension. For this example, I saved the text file as Sample.ps1.

How you execute the script depends on where it's launching from. In most cases, you'll launch scripts from within EMS.

Before you run a script you need to know the name of the script and its location. In my example, I took the Sample.ps1 script and placed it in the C:\scripts folder that I created on my Exchange Server .

Even though we assigned the script with the .ps1 file extension, Windows won't execute the script automatically. You need to tell Exchange to run the script by typing a period (.), then a slash (/) and the name of the script. For example, if you wanted to run the Sample.ps1 script, you would type:


This example is simple since I haven't taken the script's location into account. This method will only work if the script is located in the C:\scripts folder . If it is not the same in your example, you need to switch to the correct folder before calling the script.

To switch to the C:\Scripts folder and run the Sample.ps1 script, open Exchange Management Shell and enter the following commands:

CD \Scripts

If you want to include the script's location in the call, open Exchange Management Shell and enter this command:


The command doesn't include the dot slash (./) because EMS doesn't require it if you supply the script's location within the call. In fact, the script won't run if you use (./).

About the author:
Brien M. Posey, MCSE, is a seven-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.

Do you have comments on this tip? Let us know.

Dig Deeper on Exchange Server setup and troubleshooting