If you missed the first part in this article series please read Testing Exchange 2007 With PowerShell (Part 1).
Introduction
In part one of this two-part article I introduced the Exchange Management Shell cmdlets that start with Test- that can be used to test the configuration and operation of your Exchange 2007 servers prior to placing them into production. Of course, these cmdlets can also be used to help resolve issues that occur after the servers have been placed into production. In the first part of this article we looked at the Test-ServiceHealth and Test-OutlookWebServices cmdlets. In this second part of this article, we’ll cover the Test-MAPIConnectivity, Test-ExchangeSearch, Test-OwaConnectivity, Test-WebServicesConnectivity, Test-PopConnectivity and Test-ImapConnectivity cmdlets.
Test-MAPIConnectivity
Perhaps the most obvious connection method for a client is via MAPI, for which a simple test of connectivity can be made via the Test-MAPIConnectivity cmdlet. As you can probably guess, this cmdlet needs to log onto a mailbox to test functionality and therefore you can use the –Identity parameter to identify this target mailbox. Having said this, if you don’t specify a particular mailbox, the cmdlet will log into the SystemMailbox found on each database.
Also, it’s worth pointing out that you can use the –Database parameter to identify the particular database that you’d like to log into. If omitted, all databases on the local server are logged into. As with many of the other cmdlets, you can use the –Server parameter to control which server you’d like to test. The output that you get from this cmdlet is shown in Figure 6. The actual cmdlet run to produce this output was simply the Test-MAPIConnectivity cmdlet with no additional parameters supplied, meaning that both databases were logged into on the local mailbox server. Notice the latency information supplied, showing the delay in logging into each mailbox.
Figure 6: Test-MAPIConnectivity Output
If issues are encountered during the mailbox logon process the Result column will show the wording *FAILURE* and the Error column will give a description of the error. For example, the Error column will read Database is dismounted if the database being tested is dismounted.
Test-ExchangeSearch
Somewhat related to the testing of the connectivity to mailboxes is the testing of content indexing for correct functionality. The Test-ExchangeSearch cmdlet can be used for this process and it works by creating a message with an attachment that can only be found by the Exchange Search service. Since content indexing is enabled by default in Exchange 2007, it’s definitely worth testing that information can be retrieved successfully and in a timely manner before loading the server with users. The actual cmdlet to use is very simple:
Test-ExchangeSearch –Server <SERVER>
Figure 7 shows the result of performing this cmdlet with no additional parameters supplied. As you can see the cmdlet is searching the SystemAttendant mailbox and is being searched on the local mailbox server since no –Server parameter was supplied.
Figure 7: Test-ExchangeSearch Progress
At the end of the process the results are displayed and as you can see from Figure 8 the item was successfully found in a time of 9 seconds. One of the key parameters for the Test-ExchangeSearch cmdlet is the –IndexingTimeout parameter which controls how long the process will wait to search for an item before returning an error. The default setting is 120 seconds which is a fair amount of time for such a test. If you lower this figure, the cmdlet will begin searching as shown above in Figure 7 and, if the time is exceeded, will immediately stop searching and return to the status screen shown in Figure 8, where the ResultFound column will show False with the SearchTime column showing -1.
Figure 8: Test-ExchangeSearch Output
Test-OwaConnectivity
A much more complicated cmdlet to use is the Test-OwaConnectivity cmdlet. The reason I say this is more complicated is because there are many more parameters that can be used with the cmdlet than are available with other cmdlets that I have covered so far in this article. In the main, the Test-OwaConnectivity cmdlet can be used to test all OWA virtual directories on a Client Access Server or a single URL. Let’s look at the single URL example.
To test a single URL there are two main parameters of interest, only one of which can be used at a time. These parameters are the –URL parameter and the –TestType parameter. The –URL parameter simply specifies the OWA URL that you want to test whilst the –TestType parameter can be used to test either the internal or external OWA URL. By default, the –TestType parameter will test the internal URL but you can configure it to test the external URL by entering the –TestType:External parameter.
We also need to consider the credentials we will use to log on and test OWA connectivity. This is achieved via the –MailboxCredential parameter which results in an authentication dialog window appearing into which you obviously need to supply your account details. One final parameter worth considering is the –TrustAnySSLCertificate parameter which is particularly useful when you are testing internal URLs since in these cases it’s typical for the certificate name to match the external URL and not the internal URL. This parameter effectively ensures that errors such as certificate validation do not stop the OWA test process. Let’s have a look at the sample case where we test the local internal URL of an Exchange 2007 server called E2K7 using the administrator account credentials and trusting any SSL certificate. The cmdlet that will be used is:
Test-OwaConnectivity –URL https://E2K7/owa -MailboxCredential (Get-Credential NGH\Administrator) -TrustAnySSLCertificate
The output of this cmdlet is shown in Figure 9.
Figure 9: Test-OwaConnectivity Output
As with many of the other cmdlets detailed within this article, you can see the latency of the process is shown together with an overall success or failure result. If we elected not to implement the trusting of any SSL certificate and our certificate had a different name than the name used in the –URL parameter, we’d expect to see an error generated such as:
“WARNING: The test was unable to log on to Outlook Web Access because the SSL certificate did not validate.”
This is shown in Figure 10.
Figure 10: Test-OwaConnectivity Failure
Test-WebServicesConnectivity
To test the functionality and configuration of Outlook Anywhere you can use the Test-WebServicesConnectivity cmdlet. Like the Test-OwaConnectivity cmdlet this is also a reasonably complex cmdlet in that many different parameters can be used. However, on a basic level the following cmdlet can be used to test Outlook Anywhere:
Test-WebServicesConnectivity –ClientAccessServer E2K7 –MailboxCredential (Get-Credential NGH\administrator)
You’ll notice that we are again using the Get-Credential cmdlet to retrieve the relevant account name and password and in this case we’re communicating with a Client Access Server called E2K7. Figure 11 shows the result of running this cmdlet where you can see the various tests performed and the resulting latency.
Figure 11: Test-WebServicesConnectivity Output
This cmdlet is also useful in guiding you along the way to solving configuration issues. For example, look at the output in Figure 12 where you’ll see the error message listed that pointed me to a certificate configuration issue in a particular system.
Figure 12: Test-WebServicesConnectivity Failure
Test-PopConnectivity and Test-ImapConnectivity
It comes as no surprise to learn that the Test-PopConnectivity and Test-ImapConnectivity cmdlets are used to test the functionality of the POP3 and IMAP4 services. Some of the key parameters to use with these cmdlets include the –ClientAccessServer and –MailboxCredential parameters to create a logon either via POP3 or IMAP4. For example, the cmdlet below produced the results shown in Figure 13.
Test-PopConnectivity –ClientAccessServer E2K7 –MailboxCredential (Get-Credential NGH\Administrator)
Figure 13: Test-PopConnectivity Failure
Again you can see the overall result of the test as well as the latency. It’s pretty obvious from looking at the Error column what the problem as, since the POP3 service is disabled by default on a new installation of Exchange 2007. To balance things out, here’s what you should see for a successful login.
Figure 14: Test-PopConnectivity Success
Earlier in this article we saw how the Test-ExchangeSearch cmdlet had the –IndexingTimeout parameter to control how long the test waited before deciding that the items could not be retrieved from the information store in a timely manner. Both the Test-PopConnectivity and Test-ImapConnectivity cmdlets also have the –Timeout parameter for controlling timeouts, with a default setting of 30 seconds. I encourage you to check out the other parameters that these test cmdlets have.
MonitoringContext Parameter
If you have looked at the parameters available with each Test cmdlet, you may have noticed one parameter that is always listed as an option, namely the MonitoringContext parameter. This parameter is actually used by the Exchange Management Pack for Systems Center Operations Manager (SCOM). What this parameter actually does is to return both monitoring events and performance counters as well as the information supplied that you have seen from the screen shots throughout this article.
If you want to see this information within the output of your cmdlets, just include the MonitoringContext parameter. It’s a simple Boolean parameter and thus the possible options are therefore $true or $false. If the MonitoringContext parameter is set to $true, you will receive additional information relating to monitoring events and performance counters. For example, Figure 15 shows the results of the Test-MAPIConnectivity cmdlet used with the MonitoringContext parameter set to $true. Notice the full latency values given within the PerformanceCounters section rather than the rounded-up values that you saw earlier in Figure 6.
Figure 15: Test-MAPIConnectivity Output With MonitoringContext
Summary
Over the two parts of this article I have introduced the various Test- cmdlets that you can use to test the configuration and operation of your Exchange 2007 servers. As I’ve said throughout this article there are many additional parameters that can be used, so I really do encourage you to check out these cmdlets fully and remember to use them when testing your Exchange environment.
If you missed the first part in this article series please read Testing Exchange 2007 With PowerShell (Part 1).
