This content is part of the Essential Guide: The essential guide to PowerShell in Exchange

Five Exchange 2013 PowerShell techniques every admin should know

A strong handle on PowerShell is necessary to effectively manage Exchange 2013. These five Exchange 2013 PowerShell tips will prove indispensable.

PowerShell has become the preferred tool for managing Microsoft server products. Therefore, it is crucial that...

every Exchange Server 2013 administrator not only learn PowerShell, but become proficient in it. Numerous management tasks in Exchange 2013 simply cannot be performed through the graphical user interface. Here you'll find five PowerShell management techniques every Exchange 2013 administrator should have at the ready.

Establish a remote session

Windows Server 2012 makes it possible to establish a PowerShell session with a remote server. This means you don't have to enter PowerShell commands directly into the server you're managing. To establish a remote PowerShell session, use the Enter-PSSession cmdlet, followed by the name of the remote server.

For example, if you want to establish a session with a server named Exch3, use the following command:

Enter-PSSession Exch3

Once the session is established, any PowerShell commands you enter will run against the remote server. When you're finished with the session, disconnect it using the Exit-PSSession cmdlet.

Perform an action against multiple Exchange 2013 servers

You may have instances where you need to run a single PowerShell command against multiple Exchange 2013 servers. Fortunately, it's easy to do so using the Invoke-Command cmdlet. This cmdlet requires you to specify the names of the servers you want to run the command against, as well as the command you want to run.

For example, let's say you want to run the Get-Mailbox command on servers Exch1, Exch2, and Exch3. The resulting full command would be the following:

Invoke-Command –ComputerName Exch1,Exch2,Exch3 {Get-Mailbox}

As you can see, you must first specify the target server names, then include the command you want to run inside a pair of brackets. This brings us to another important tip.

Run a command within a command

Sometimes the only way to accomplish a management task with PowerShell is to enter a command within a command. With this technique, the secondary command is enclosed in brackets ({}). As an example, let's say you want to provision storage for a new Exchange 2013 server and need to create a Windows storage pool. The required cmdlet here is New-StoragePool.

The New-StoragePool cmdlet requires you to enter three pieces of information: a friendly name, the name of the storage subsystem and the physical disks you want to include. The problem here is that you may not know the storage subsystem name or the names of the physical disks eligible for inclusion in a storage pool. Assuming that you're OK with including every eligible disk in the new storage pool, you can create the pool using the following command:

New-StoragePool –FriendlyName “My Storage Pool” -StorageSubSystemFriendlyName {Get-StorageSubsystem –FriendlyName *space*} –PhysicalDisks {Get-PhysicalDisk –CanPool $True}

In the above command, note that there are two instances where code is enclosed in brackets; these are subcommands. As you can see, the last part of the command issues the PhysicalDisks parameter. Since we don't have the name of the physical disks, we can insert a bracket and include the Get-PhysicalDisk cmdlet to retrieve a list of physical disks to use in the command.

Filtering Exchange 2013 PowerShell command outputs

Exchange Server admins often use Get commands to retrieve different types of information. That said, Get commands often return considerably more information than what is actually needed. It's nice to have the option to narrow down the list of results, especially when piping the results list into another PowerShell cmdlet. Fortunately, PowerShell lets you do so through filtering.

Suppose you want to retrieve a list of the RBAC role groups that a user belongs to. If you enter the Get-RoleGroup cmdlet, you will receive a list of all role groups that exist in your Exchange 2013 organization.

The trick to narrowing down the list is to enter the Get-RoleGroup command, followed by the name of a role group. You should then format the result as a list. For example, let's assume one of the role groups is named Organization Management. Therefore, use the following command:

Get-RoleGroup 'Organization Management' | FL

Formatting the output as a list displays the parameters that are valid for the cmdlet. In this case, group membership is tied to the Members parameter. With that in mind, let's assume you want to filter the output to compare the Members attribute against a specific member name. That command would look something like the following:

Get-RoleGroup | Where-Object {$_.Members –EQ 'Contoso/Users/User1'}

In the above command, the Members parameter is treated as a variable. That's why there is a dollar sign ($), underscore (_) and period (.) in front of it. The –EQ is the Equals operator, which is followed by the username.

If this filtering method seems complicated, there is some good news. In Windows Server 2012, Microsoft simplified PowerShell syntax by removing the requirement for attributes to be expressed as variables when performing Where-Object filtering. Therefore, in Windows Server 2012 the command may be expressed as the following:

Get-RoleGroup | Where Members –EQ 'Contoso/Users/User1'

The What-If parameter

There's no doubt that PowerShell can prove complicated, and sometimes there can be very unpleasant consequences to entering an Exchange 2013 PowerShell command incorrectly. If you're ever unsure of what a command will do, consider appending the What-If parameter to the end of the command. Doing so is akin to asking PowerShell what would happen if you actually ran the command.

For example, suppose you were curious about running the Update-GlobalAddressList cmdlet, but weren't sure exactly how it would affect your environment. You can append –WhatIf to the end of the command string to find out what happens if you ran the command without actually doing so.

Note: It's important to understand that the What-If parameter doesn't work with every PowerShell cmdlet. To see a list of the cmdlets that you can use What-If with, enter the following command:

Get-Command | Where Definition –Like *whatif*

About the author:
Brien Posey is a ten-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as chief information officer at a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.

Dig Deeper on Exchange Server setup and troubleshooting