Using Test Cmdlets for the Client Access Server Role
Several important Test cmdlets are also available for testing Client Access Servers. As shown in the following table, these cmdlets can test client connectivity to the Client Access Server, Exchange services status on the Client Access Server, whether the PowerShell remoting capability is functioning correctly, and so on.
Use the following script to create the required user for the test:
Before executing the Test-WebServicesConnectivity cmdlet, run the script New-TestCasConnectivityUser.ps1 to create a user that the cmdlet uses to test connectivity.
Tests the functionality of Exchange Web Services (EWS) on a server that has the Client Access Server role installed.
Note
Exchange Web Services replaces many of the features found in WebDAV, CDOEX, and ExOLEDB, thus potentially reducing problems with applications requiring these earlier APIs.
Tests the health of an instance of the Mailbox Replication service on one or more Client Access Servers.
In the example, you test all Client Access Servers.
PS C:\Users\Administrator>
Test-PowerShellConnectivity-ClientAccessServerRomac-EX2-VirtualDirectoryName "PowerShell(Default Web Site)"-TrustAnySSLCertificate
Tests whether Windows PowerShell remoting on a Client Access Server is functioning correctly.
Note
This example tests the PowerShell (Default Web Site) virtual directory on the specified server. The switch -TrustAnySSLCertificate is used to skip the certificate check during connection.
Tip
This cmdlet uses the same user account created when you ran the script New-TestCasConnectivityUser.ps1 previously.
Tests for a connection to each service (note that quite a few are tested).
It also submits a request to the Availability service for the specified user to determine whether the user’s free/busy information is being returned correctly from the Client Access Server to the Outlook client.
You are currently reading a PREVIEW of this book.
Get instant access to over
$1 million worth of books and videos.