Look for a wrap-up article in Part 5 and 6 of this series when I basically combine all of these cmdlets into one test script that can be used for your test or production environments. My plan is to have a menu driven script that can be used to run blocks of code or test sections. The menu will also include an all tests option that will allow for a one stop show for generating a test script. I also plan on creating a script that can be scheduled, but that is more pie in the sky at the moment than an actual plan.

Test-OutlookWebServicesUse the Test-OutlookWebServices cmdlet to verify the Autodiscover service settings for Microsoft Outlook on a computer running Microsoft Exchange Server 2013.

A basic run of the PowerShell command without any switches provides us with a quick view into the status of the various services for Outlook Anywhere:

The same command run with the ‘-verbose’ switch. Notice the extra details that are revealed (what is tested as well as results):

More ‘-verbose’ results:

More ‘-verbose’ results:

More ‘-verbose’ results:

This PowerShell test cmdlet has a few Options to further customize your results:

AutoDiscoverServer – Specify which server to use for AutoDiscover

ClientAccessServer – Specify which CAS server to test

MailboxCredential – Specify which mailbox to test for one-off testing

Identity – Specify a valid email address to test

TrustAnySSLCertificate – Specify this if a certificate cannot be verified

The best use of this is to run a loop with a separate test per CAS server. Code for this will be at the end of the post.

Test-PopConnectivityUse the Test-PopConnectivity cmdlet to verify that the POP3 service is running as expected. The Test-PopConnectivity cmdlet can be used to test the POP3 functionality for a specified Client Access server for all mailboxes on servers running Microsoft Exchange Server 2013 in the same Active Directory site.

A base run of the command leads to a failure in my test environment:

Checking the configuration appears to reveal that all settings are correct (although I am using PlainText, adding this to the above test also fails). Port 995 and SSL are in use.

So what will allow a good test of POP for a lab or production environment?

Test-popconnectivity -lightmode

** Lightmode simply tests the login of the POP protocol, without this switch a test messages are sent and received.

PerConnectionTimeout – default is 120 seconds, this is the time the command will wait for a test to timeout

PortClientAccessServer – Specify a custom port to connect on for the POP test

Timeout – Timeout for the entire test, default is 180 seconds

TrustAnySSLCertificate – Specify this if a certificate cannot be verified

Test-PowerShellConnectivityThe Test-PowerShellConnectivity cmdlet connects to a Client Access server to test whether Windows PowerShell remoting on that server is working correctly and whether the Client Access server can perform commands against a remote Mailbox server.

Base run of the cmdlet reveals quite a bit of information on the PowerShell vDir:

TrustAnySSLCertificate – Specify this if a certificate cannot be verified

Test-ReplicationHealthUse the Test-ReplicationHealth cmdlet to check all aspects of replication and replay, or to provide status for a specific Mailbox server in a database availability group (DAG).

I ran a the base cmdlet against my test environment – notice what happens when a server in a DAG cluster is down:

Use ‘test-replicationhealth |fl’ to get more information on the error message:

The cmdlet also has additional parameters to use:

ActiveDirectoryTimeout – Allows for additional time for AD queries, default is 15 seconds

DomainController – Specify which Dc is queried by the cmdlet

Identity – Specify mailbox server to test

OutputObjects – changes the output of the command to include the identity column

TransientEventSuppressionWindow – specifies the number of minutes that the queue lengths can be exceeded before the queue length tests are considered to have failed

OutputObjects parameter:

Test-SenderIdUse the Test-SenderIdcmdlet to test whether a specified IP address is the legitimate sending address for a specified SMTP address.

Configured in DNS – Microsoft.Com

Not configured – CNN.Com:

Parameters that are available for Test-SenderID are:

IPAddress – external IP of Exchange or remote mail server to test

PurportedResponsibleDomain – SMTP domain to test

DomainController – Specify which Dc is queried by the cmdlet

HelloDomain – specifies the domain address displayed in the HELO or EHLO SMTP commands from this sender

Server – Specify which Exchange server to run this from

At the bottom of this article I have sample PowerShell code that will test each accepted domain’s SenderID status.

Test-ServiceHealthUse the Test-ServiceHealth cmdlet to test whether all the Microsoft Windows services that Exchange requires on a server have started. The Test-ServiceHealth cmdlet returns an error for any service required by a configured role when the service is set to start automatically and isn’t
currently running.

No options, a good quick report is provided:

Abbreviated:

test-servicehealth |ft role,require*,ServicesNotRunning -auto

Parameters for Test-ServiceHealth:

ActiveDirectoryTimeout – Allows for additional time for AD queries, default is 15 seconds

DomainController – Specify which Dc is queried by the cmdlet

Server – Specify which Exchange server to test

Test-SiteMailboxUse the Test-SiteMailbox cmdlet to test the site mailbox to Microsoft SharePoint connectivity and to test whether users have the correct permissions to use a site mailbox. This cmdlet should be used for troubleshooting and diagnostic purposes.

The below example shows the use of the bypassowner switch as well as the SharePoint server URL:

Parameters that can be used with this command:

BypassOwnerCheck – use this switch if the account running the command is not the owner of the mailbox tested

Identity – specify Site Mailbox identity

RequestorIdentity -Specify an account to test access to the Site Mailbox

SharePointUrl – Specify the SharePoint URL where the mailbox is located

UseAppTokenOnly – Test access by the Exchange server and cannot be used with the RequestorIdentty

** If there are any issues found, use the ‘Check-SiteMailboxConfig.ps1’ script to check the configuration for any possible issues.

Test-SmtpConnectivityUse the Test-SmtpConnectivity cmdlet to diagnose whether an SMTP connection can successfully be established to the Receive connectors on a specific server. Although you can run this cmdlet manually to verify SMTP connectivity for a specified server, it’s primarily used by Microsoft System Center Operations Manager 2007 to test your transport servers’ ability to receive SMTP connections to each of the bindings on all the Receive connectors on those servers.

Simplest Command:

Get-TransportService | Test-SmtpConnectivity

Notice that all the connects from the one server show as “UnableToComplete”. This server was shut down for testing these commands.

Parameters available to SMTP Connectivity testing:

DomainController – Specify which DC is queried by the cmdlet

Identity – Specify which Transport Server to test

Test-UMConnectivity Use the Test-UMConnectivity cmdlet to test the operation of a Mailbox server computer running the Microsoft Exchange Unified Messaging service.

Parameters available for the Test-UMConnectivity command:

Phone – specifies the telephone number or Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) used when the test call is redirected.

PIN – associated with the UM Enabled mailbox

ResetPIN – ($true or $false) – resets for all test mailboxes

TUILogon – ($true or $false) – tries to login to one or more mailboxes

LightMode – Only GetFolder is used for testing, all other tests are ignored

MailboxCredential – Specify the mailbox credentials to use for testing

TrustAnySSLCertificate – Specify this if a certificate cannot be verified

While testing the command, I noticed that the help file contained an option that is not available in the version I was testing:

When I tried to add the parameter to the command, I was unable to. Apparently it is not available in CU3:

**I’ve verified that this option does not exist in CU6 and the wording above was scrubbed and now shows the ‘ClientAccessServer’ switch instead.

Next Steps
In this article we’ve gotten through all of the native Exchange PowerShell Cmdlets for testing. Below I have assembled this article’s ten test cmdlets and ‘enhanced’ them to show only what should be important from each test: