PowerShell basics for the Exchange admin

.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 (./).

Throttling PowerShell command usage in Exchange 2010

Throttling PowerShell command usage in Exchange 2010

Administrative actions are based on PowerShell. Some administrative actions, like running large scripts, can be resource intensive. Throttling PowerShell can help lessen the strain on a server’s performance.

Exchange’s Web services (EWS) rely on remote shell sessions. Because of this, throttling PowerShell can help prevent a user from overloading Exchange by performing concurrent actions through multiple browsers.

Exchange Server 2010 provides several different parameters you can use to throttle PowerShell command usage. One such parameter is PowerShellMaxConcurrency. This parameter can be tricky because its function varies depending on the context.

When a user establishes a remote shell, the PowerShellMaxConcurrency parameter defines the maximum number of simultaneous remote shell sessions that a user can have open. This parameter may also be applied to EWS. In this case, the parameter controls the maximum number of cmdlets that a user can simultaneously run.

Where PowerShell throttling and throttling policy parameters differ

Unlike the PercentTimeIn parameter, PowerShell throttling parameters don’t automatically assume that you want to throttle commands based on percentages of a minute. Instead, you must explicitly define your desired throttling time period by assigning a period of time (in seconds) to the PowerShellMaxCmdletsTimePeriod parameter. After doing this, you can control the maximum number of PowerShell cmdlets that are allowed to run within the designated period by assigning a value to the PowerShellMaxCmdlets parameter.

One PowerShell throttling parameter that I recommend avoiding is PowerShellMaxCmdletQueueDepth, which controls the total number of PowerShell cmdlets that can be simultaneously queued. Using this parameter can have several side effects.

Modifying the PowerShellMaxCmdletQueueDepth parameter affects PowerShellMaxCmdlets and PowerShellMaxConcurrency settings, both of which already skew cmdlet depth. The PoweShellMaxConcurrency parameter limits the number of concurrent remote shell sessions that a user can have open, so it also limits the number of simultaneous cmdlets that can run. The parameter can also limit the number of browser sessions that a user can have open.

When you’re using the PowerShellMaxCmdletQueueDepth parameter, it has the same effect as decreasing the PowerShellMaxConcurrency setting by two. If you do decide to use this parameter, Microsoft recommends that you set its value to at least three times the value of the PowerShellMaxConcurrency parameter.

Note: Throttling the PowerShellMaxCmdletQueueDepth won’t affect the Exchange Control Panel or EWS.