Nomad_Soul - Fotolia


Eight handy Exchange 2013 PowerShell cmdlets

There are hundreds of new cmdlets in Exchange 2013, but these eight PowerShell cmdlets will help you manage, monitor and troubleshoot the Exchange 2013 setup.

Microsoft has been developing products that can be deployed and fully managed with PowerShell for some time now....

Exchange Server 2013 is part of the push for organizations to use more of the PowerShell scripting language.

You can only manage the latest iteration of Exchange Server using the Exchange Administration Center to some extent -- there are some configurations not exposed in the graphical user interface that can be found with scripts. Certain Exchange 2013 PowerShell CmdLets can help you develop simple scripts for managing and monitoring your messaging platform.

There are nearly 200 new cmdlets -- lightweight PowerShell commands -- in Exchange 2013. These eight Exchange 2013 PowerShell cmdlets will help you manage, monitor and troubleshoot your Exchange 2013 setup.


Use this cmdlet for a snapshot of your Exchange 2013 licensing, including the number of standard and enterprise client access licenses (CALs) and the edition of Exchange 2013: Standard or Enterprise. There are no parameters for this cmdlet, and it will only work for on-premises Exchange 2013 deployments. The cmdlet's syntax is:



This cmdlet can be used to retrieve the configuration settings for Exchange 2013 components and endpoints. To retrieve the component state for hub transport, the syntax is:

Get-ServerComponentState -Identity <serverid> -Component HubTransport

Use this command to find the status of all Exchange 2013 components. The components will have one of the three statuses -- active, inactive or draining (Figure 1).

Get-ServerComponentState -Identity <serverid>

Exchange 2013 components status
Figure 1


Get-ServerHealth returns the health information for a specified Exchange 2013 server. It only works for on-premises deployments and returns an alert value that specifies the state of the server (see Figure 2). The alert value can be: Degraded, Unhealthy, Repairing, Disabled, Unavailable and Uninitialized. The syntax for this Exchange 2013 PowerShell cmdlet is: 

Get-ServerHealth -Identity <serverid>

Exchange 2013 health alert
Figure 2


This Exchange 2013 PowerShell cmdlet eases license management. Use it to find the end users who require Exchange 2013 Standard and Enterprise CALs.

Get-ExchangeServerAccessLicenseUser -LicenseName "Exchange 2013 Standard CAL" provides a list of users who need standard CALs.

Run Get-ExchangeServerAccessLicenseUser -LicenseName "Exchange 2013 Standard CAL" | Measure-Object, to get the actual end user count, which helps when purchasing licenses.

By tweaking the syntax, Exchange 2013 admins can find the actual number of end users who need the CALs; this information can make purchasing the client access licenses much easier.


Use the Get-HealthReport cmdlet to find out the status of every health set in the Exchange 2013 server (see Figure 3). The syntax is:

 Get-HealthReport -Identity <serverid>

These values can be returned for the health value:

  • Online
  • Partially online
  • Offline
  • Sidelined
  • Functional
  • Unavailable
Health set values in Exchange 2013
Figure 3


Use this Windows PowerShell command to check all aspects of Exchange 2013 replication related to the mailbox servers in a database availability group (see Figure 4). The syntax is:


Check Exchange 2013 replication
Figure 4


This cmdlet is handy if you want to move the message queues on an Exchange 2013 mailbox server to another server. Active messages on the source mailbox server are routed to the target mailbox server when the messages are drained. The source server won't take any messages while the queues are drained.

To specify the source and target 2013 mailbox servers, admins use:

Redirect-Message -Server <source server> -Target <target server>


This Exchange 2013 PowerShell cmdlet allows you to test email delivery between two mailboxes -- on the same server or different ones. The cmdlet uses system mailboxes by default, but you can specify another mailbox for the test (see Figure 5).

Test email delivery in Exchange 2013
Figure 5

In this case, you need to run the cmdlet on the source server. The syntax is:

 Test-Mailflow <source server name> -TargetMailboxServer <target server name>

You can test the mail flow to an email address by running:

 Test-MailFlow <server name> -TargetEmailaddress <email address>

About the author:
Rajith Enchiparambil is a UC Architect who works on large Exchange and Office 365 projects for clients in the U.K. He specializes in Exchange, Office 365, Active Directory and a bit of Lync. He has been working in the IT industry for the last 13 years and has worked extensively with Microsoft Exchange since version 5.5. Enchiparambil has worked for consultant services such as HP, Siemens, AtoS, CapGemini and Computacenter. He regularly writes about Office 365 and Exchange in his personal blog,

Next Steps

Five PowerShell techniques all Exchange 2013 admins should know

PowerShell changes for public folders in Exchange 2013

Dig Deeper on Exchange Server setup and troubleshooting