5 Essential PowerShell Skills for Exchange Server Administrators

Ask an experienced Exchange administrator and they’ll tell you that learning PowerShell is important to be able to do the job well. Even though most administrative tasks can be performed using the Exchange Management Console it tends to be much slower to navigate, and is less efficient for doing bulk administration. If you’re still holding yourself back from learning PowerShell, then here are five tips to help get you started.

Discovering Commands

One of the first challenges with using PowerShell for Exchange Server management is knowing which commands to run for the task you want to perform. Fortunately you only need to remember one: Get-Command.

Using Get-Command you can quickly search for cmdlets based on keywords. Let’s say for example you want to administer a mailbox. Using Get-Command you can discover all of the cmdlets that have the noun “mailbox” in them.

With PowerShell’s simple “Verb-Noun” cmdlet names you can now quickly see which cmdlet to use if you want to get a list of mailboxes, set a mailbox property, or create a new mailbox.

Filtering Output

Some PowerShell cmdlets return a lot of data. For example if you run Get-Mailbox it will return every mailbox in your organization. That may be hundreds or thousands of mailboxes, when all you really wanted is the mailboxes that match a certain criteria. PowerShell lets you filter the data that a cmdlet returns by using the Where-Object command, or simply “where” as it is often abbreviated. For example, to get the list of mailbox users in the branch office of the organization you can run the following command:

As you can see by filtering the output of Get-Mailbox to only those where the “Office” attribute equals “Branch Office”, you can retrieve only the data that you are interested in seeing.


Using the Pipeline

One of the PowerShell techniques you will use regularly is the pipeline. In PowerShell the pipeline is how output from one command is passed to another. You may have noticed in the previous example the | (or pipe) character that was between the Get-Mailbox and Where-Object cmdlets. That is an example of the pipeline in action. Continuing the previous example, let’s say that the business has decided that all branch office mailbox users should have a 3Gb mailbox storage quota. You can use the same command shown above to get the branch office mailboxes, and then pipe that into the Set-Mailbox cmdlet to make the change to their storage quota settings.

Now when we look at the list of branch office mailboxes again we can see the change to the storage quota settings.


Discovering Object Properties

PowerShell is an object-oriented language. If you don’t know what that means then don’t worry, I was using PowerShell for almost two years before I began to understand what it meant.
An “object” is simply a collection of data. In Exchange Server 2010 an object could be a mailbox, a distribution group, a database, or one of many other things.

An object has properties. In the example of a mailbox object these include properties such as the name of the database the mailbox resides on, the mailbox storage quota values, or the office location for the mailbox user. In the previous examples we looked at filtering mailboxes using the “Office” attribute, and setting the values for mailbox storage quota attributes. But how do we know which properties a mailbox object has, so that we can perform that filtering or apply changes to those settings?

Again PowerShell gives us the answer thanks to the Get-Member cmdlet. Get-Member will list all of the properties of an object to help you learn what you can and can’t do with them. For example, to discover which properties the mailbox object has you can run the following command (note once again the use of the pipeline):

I’ve had to truncate the output in this example because it returns quite a long list of properties that mailbox objects have. It would be more convenient to filter the list down to just the properties I might be interested in. So let’s say that we just want to see which mailbox object properties relate to quota settings. Once again we can use the pipeline and filtering to achieve that.

Pretty neat isn’t it.



The last essential skill that I’ll demonstrate to you in this article is remoting, which is a feature available in PowerShell 2.0 and above. Exchange Server 2010 servers require at least PowerShell 2.0, so this technique will work for Exchange 2010 environments. Remoting is simply the technique of connecting a PowerShell session on the local computer to a remote server. This is useful if you are logged on to a workstation that has PowerShell installed, but doesn’t have the Exchange Server 2010 management tools installed, and you need to run some Exchange management tasks. By remoting from the workstation to an Exchange 2010 server you quickly get access to all of the Exchange cmdlets.

To demonstrate, here is a PowerShell window on a workstation that does not have the Exchange 2010 management tools installed. Notice that the Get-ExchangeServer cmdlet returns an error because it doesn’t exist on that workstation.


Now let’s remote to an Exchange 2010 server and try running the cmdlet again.  There are two steps for PowerShell remoting. The first is to create a new PowerShell session object using New-PSSession.

Notice the URI that the session is connecting to? That is the /powershell virtual directory in IIS on the Exchange 2010 server named “ho-ex2010-mb1”. After you have created the new session object you can import it using Import-PSSession.


Now let’s try the Get-ExchangeServer cmdlet again.


This time it works, thanks to PowerShell remoting.

As you can see from this article PowerShell is not a daunting language to learn and to begin using on a daily basis once you understand a few of the fundamental skills involved. Try some of these yourself and let us know in the comments below if you have any questions.

Filed in: Articles, Online Only Tags: , ,

16 Responses to "5 Essential PowerShell Skills for Exchange Server Administrators"

  1. Anonymous says:

    For your filter example, you should use the Filter parameter of the Get-Mailbox cmdlet:
    Get-Mailbox -Filter {Office -eq “Branch Office”}


    • Hi Karl, the -Filter parameter has some caveats, such as not being able to be used in conjunction with some other parameters. It also doesn’t work at all with some other Get-* cmdlets. Since the example is more about learning the skill of filtering in general as opposed to the best way to filter Get-Mailbox results, I went with Where-Object for the article instead.

      But yes, -Filter is sometimes the better way to go.

  2. Anonymous says:

    Great article, Paul. The stuff on remoting is particularly useful. I am a huge fan of management servers and workstations, rather than logging directly onto the server. It’s great to see this theory being applied for Exchange as well.

  3. Ewalton says:

    Pretty good. i have been trying to use Powershell to parse a user’s mailboxes to locate any emails that have attachments over 25mb.

    any ideas on how do this. coming up empty when trying to write it myself or using bing to find answer.


  4. I agree with Paul. “Filter ” works faster when it could work, but has some limitations.

  5. KB says:


      I’m hoping that someone may be able to assist me. I’ve been able to successfully use PowerShell to obtain a list of users that are listed in the AcceptMessagesOnlyFrom attribute in a distribution list but for some reason, I only receive a partial listing and not the entire list.  Here’s the command I’m using:

    Get-distributiongroup -identity “DLName”
    | fl AcceptMessagesOnlyFrom >c:members.txt

    Working w/Exchange 2007, SP2.  Thanks for any advice you provide.


  6. Thanks @Paul for the detailed information about PowerShell commands. Though you have great expertise i would like to request you please visit mentioned link and share your reviews about written blog on PowerShell – http://goo.gl/PyYJLC

  7. Reyasat says:


    I have one issue in Exchange server 2010. If I am running Exchange they are showing the following error. How I can solve this issue?????

    using “Kerberos” authentication failed: connecting to remote server failed.

    waiting for your prompt replay



  8. praveen says:

    Hi Paul,

    I am a 3yrs experienced CCNA Routing & Switching engg in an ISP, looking job in Exchange server. In many of my Job ads i seen scripting language like Power shell, Perl, Shell Scripting. I am new to this scripting language. I am interested to learn this power shell language to change my career into IT field. Can you guide me career steps, books of power shell.
    I am waiting for your reply.

    Thanks & Regards,

  9. JerryLu says:

    Hello Paul,

    Could you please let me know if below command will change user first name and email address in Active Directory?? These steps were advised in one tech note to resolve Global Address list issue. So I applied on Exchange server.

    Update-GlobalAddressList -Identity “Default Global Address List”
    get-mailbox get-mailbox -ResultSize “Unlimited” | set-mailbox -applymandatoryproperties


Leave a Reply

Submit Comment

© 2016 PowerShell Magazine. All rights reserved. XHTML / CSS Valid.
Proudly designed by Theme Junkie.
%d bloggers like this: