You’re probably already aware of how you can achieve greater levels of productivity and automation using PowerShell. To be clear though, PowerShell is not so much created for managing Exchange Server as a powerful task automation framework consisting of a command-line shell and an associated scripting language that is integrated with the .NET Framework. PowerShell can also be used to access COM and WMI objects to perform administrative tasks on local and remote Windows systems.

Below are some tips to quickly get up to speed on certain important aspects of using PowerShell with an Exchange Server deployment.

Connecting to Exchange Online using PowerShell

As its name suggests, Exchange Online is the cloud-based version of Exchange Server. The growing acceptance of cloud services is resulting in businesses that eschew buy their own physical servers, or who may opt for a hybrid deployment involving both Exchange Online and an on-premise Exchange Server. Fortunately, it is possible to connect to Exchange Online using PowerShell too; here’s how:

To initiate an Exchange Online session, first type in the following command in a PowerShell session. You will be prompted for your admin credentials:

$LiveCred = Get-Credential

Once done, create a new remote PowerShell session with the following command:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $LiveCred -Authentication Basic –AllowRedirection

Next, import the cmdlets to your local PowerShell session:

Import-PsSession $Session

You can now execute various cmdlets; you can use the command below to view information about cloud-based mailboxes:


When done, be sure to disconnect from the server-side session with the following:

Remove-PSSession $Session

For additional information about the cmdlets that are available in Exchange Online, you can check out this reference here.

Creating PowerShell Scripts

While the PowerShell command line offers extraordinary flexibility in performing all manner of tasks, its real power lies in the ability to create custom scripts for performing various regular management tasks. This also promotes code reuse, which has the added effect of reducing errors resulting from typos or outright mistakes.

To be clear, a PowerShell script is essentially a text file with a .PS1 extension, which allows it to be edited using the PowerShell Integrated Scripting Environment (ISE) or any common text editor such as Windows Notepad or NotePad++. Variables, conditional logic (if, else) and loops (do while, while, do until, for, for each) are other important aspects of PowerShell that Exchange administrators working with scripts will need to be familiar with.

To write scripts for managing Exchange Online or other remote Exchange Servers, it may be necessary to first store the login credentials so that the housekeeping scripts may be launched at predetermined times outside office hours. Rather than having the passwords in plaintext within the script, a much safer alternative would be to write an encrypted version of it to a local file. This can be done with the following command:

Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File C:\Users\someone\MyPassword.txt

Within your PowerShell script, the encrypted password credential can be accessed using the following snippet:

$Password = type C:\users\someone\MyPassword.txt | ConvertTo-SecureString

$Userid =

$Cred = New-Object System.Management.Automation.PSCredential ($Userid, $Password)

It is important to note that although this method is more secure than having the plain text password written in the script itself, a few risks remain. Anyone who manages to get access to the script can alter it to perform unauthorized actions which can compromise the security of your Exchange Servers. Furthermore, if someone with malicious intent gets access to the system and is able to run his/her own scripts he/she can still retrieve the password from the SecureString itself. That said, it is a good middle ground between convenience and security for most.

Finally, organizations with more than one Exchange admin in place may also want to create a common repository to store useful scripts that can be shared internally. Depending on the storage environment, this repository of scripts and functions – mentioned below, can also be added to the system path for easy access.

Piping the output of Cmdlets, Functions

Not everything requires the hassle of writing a script though. For simpler tasks, it may make more sense to pipe the output of a cmdlet to another for the desired output. While this may require more command line and PowerShell knowledge than the average Exchange administrator may possess, chaining various cmdlets into a single command is an enormously powerful way of performing complex Exchange tasks.

Building on the idea of code reuse mooted above in “Creating PowerShell Scripts”, would be the idea of packaging them into functions. As opposed to the single purpose usage of a script, a function can be called and its output reused or even piped to another cmdlet as necessary. Used correctly, piping the output of one cmdlet to another can be used to quickly perform tedious configuration changes. The following configures all mailboxes with a quota of 3GB with a warning set at 2.8GB (source):

Get-Mailbox | Set-Mailbox -IssueWarningQuota 2.8GB -ProhibitSendQuota 3GB

This may also be further filtered by selecting only those accounts where the “Office” attribute matches that of the “Main Office.” The result would look something like this:

Get-Mailbox | Where-Object {$_.Office -eq “Main Office”} | Set-Mailbox -IssueWarningQuota 2.8GB -ProhibitSendQuota 3GB

Though we have really only scratched the surface with the tips outlined above, PowerShell is capable of greatly simplifying the work for Exchange admins. With its increasing role in the Windows Server operating system and the latest improvements in PowerShell 3.0, its role in the management of Exchange environments will only become more important.


Like this post?

If you like this post and would like to receive more Exchange Server tips, as well as the latest Exchange Server posts from across the web, plus a free ebook with 42 Exchange tools, subscribe to the IT Dojo – Exchange Sensei series!


Get your free 30-day GFI LanGuard trial

Get immediate results. Identify where you’re vulnerable with your first scan on your first day of a 30-day trial. Take the necessary steps to fix all issues.