Test-OutlookWebServices Test-PopConnectivity Test-PowerShellConnectivity Test-ReplicationHealth Test-SenderId Test-ServiceHealth Test-SiteMailbox Test-SmtpConnectivity Test-UMConnectivity Test-WebServicesConnectivity
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-OutlookWebServices
Use 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-PopConnectivity
Use 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.
As we can see from above, POP3 is working as expected.
Parameters [most relevant for testing]
- ClientAccessServer – Specify which CAS server to test
- ConnectionType – [plaintext | TLS | SSL] – Select your authentication method
- Domain Controller – Specify which Domain Controller to test against.
- MailboxCredential – For an individual mailbox test
- MailboxServer – Specify which Mailbox server to test
- 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-PowerShellConnectivity
The 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:
There are also a few parameters that can be used with this command:
- ConnectionUri – Good for testing a load balanced URL. By default the local http link ‘http://server.domain.com/powershell’ is tested.
- TestCredential – Specify what credentials to test with
- Authentication – Default | Basic | Negotiate | NegotiateWithImplicitCredential | Credssp | Digest | Kerberos
- ClientAccessServer – Specify which CAS server to test against
- Domain Controller – Specify what DC to query against for AD lookups
- TestType – internal or external
- TrustAnySSLCertificate – Specify this if a certificate cannot be verified
Test-ReplicationHealth
Use 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-SenderId
Use 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-ServiceHealth
Use 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-SiteMailbox
Use 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-SmtpConnectivity
Use 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
- TUILogonAll -($true or $false) – log into all UM mailboxes
- UMDialPlan – specify Diam Plan to test
- UMIPGateway – Specify gateway to test for outgoing test call
- CallRouter – Specifies the CAS server to test call routing
- CertificateThumbprint – specifies the certificates thumbprint used for SIP Secured/Secured testing
- DiagDtmfDurationInMilisecs – Duration of each digit sent
- DiagDtmfSequence – Specify sequence of digits sent
- DiagInitialSilenceInMilisecs – Specify MS pause before digit sequence
- DiagInterDtmfDiffGapInMilisecs – Specifies whether to customize the time between the digits in the sequence
- DiagInterDtmfGapInMilisecs – Time between digits in the sequence
- DomainController – Specify the DC to handle AD queries
- From – Specify originating SIP address
- ListenPort – Change default port (which is port 9000)
- MediaSecured – User secure RTP on TRP
- RemotePort – Port used for the call (5061 is the default)
- Secured – SIP Secured mode
- Timeout – Specifies time out for the entire test. (600 seconds is the default)
Test-WebServicesConnectivity
Use the Test-WebServicesConnectivity cmdlet to perform basic operations to verify the functionality of Exchange Web Services on a server running Microsoft Exchange Server 2013.
Parameters available for the cmdlet:
- AutoDiscoverServer – Specifies the server to use for AutoDiscover
- ClientAccessServer – Specify which CAS server to test against
- Identity – Specified the MailboxID to use for testing
- 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:
$cas=(Get-ClientAccessServer).name
foreach ($line in $cas) {Test-OutlookWebServices -clientAccessServer $line}
Test-PopConnectivity
Test-PowerShellConnectivity | ft localsite,clientacessserver,urltype,connectiontype,result,error -auto
Test-ReplicationHealth
$domains = (Get-AcceptedDomain).domainname
$smtp = $domains.smtpdomain
foreach ($line in $smtp) {Test-SenderId -IPAddress <external IP of Exchange server(s)> -PurportedResponsibleDomain $line}
test-servicehealth |ft role,require*,ServicesNotRunning -auto
Test-SiteMailbox
Get-TransportService | Test-SmtpConnectivity
Test-UMConnectivity
Test-WebServicesConnectivity
Past Posts in the Series
Testing Exchange Server Updates – Part 1
Testing Exchange Server Updates – Part 2
Testing Exchange Server Updates – Part 3
