Testing Exchange 2007 With PowerShell (Part 1)

If you would like to read the next part in this article series please go to Testing Exchange 2007 With PowerShell (Part 2).


After you’ve built and configured your new Exchange 2007 server, one of the first things that you should always do is thoroughly test the system before you put users onto it, even your initial pilot users.  Any issues encountered can then be resolved before they affect the users.  Microsoft has provided a whole selection of Exchange Management Shell cmdlets that can be used to test the various services and functionality of your Exchange 2007 server before you place it into production.  Of course, you can also use these same cmdlets during the lifetime of the server to re-test the functionality should you have any doubts as to whether the server is configured correctly or perhaps even optimally.  These cmdlets all start with Test-.

Recently on a project I used the various Test- cmdlets to test the configuration of an Exchange 2007 server environment that had just been built and configured.  Throughout this article I will be taking a look at some of the cmdlets that I used.  I won’t be covering every cmdlet that can be used to test server functionality since the list is fairly long.  Additionally, each cmdlet has a number of different parameters available to it and therefore equally it’s not really feasible to cover them all within this article.  What I hope to do, though, is to give you a taster of the sort of tests that can be accomplished via these cmdlets thereby ensuring that you remember to run them the next time you have either recently configured an Exchange 2007 server or you have run into an operational issue that you would like checked out.

Table 1 shows a list of available cmdlets that can be used for testing purposes with those in the shaded rows being covered in this two-part article.  The cmdlets won’t be covered in any particular order.  In this article, I’ll cover the Test-ServiceHealth and Test-OutlookWebServices cmdlet whilst the remainder will be covered in part two.

Cmdlet Name Purpose
Test-ActiveSyncConnectivity Tests the configuration of ActiveSync against a mailbox
Test-EdgeSynchronization Tests the synchronization status of subscribed Edge Transport servers
Test-ExchangeSearch Tests the content indexing service for correct functionality
Test-ImapConnectivity Tests the IMAP4 service for correct functionality
Test-IPAllowListProvider Tests the configuration of the IP Allow List provider
Test-IPBlockListProvider Tests the configuration of the IP Block List provider
Test-Mailflow Tests the sending and receiving of email
Test-MapiConnectivity Tests that a mailbox can be logged onto properly
Test-OutlookWebServices Tests the Autodiscover service settings
Test-OwaConnectivity Tests that Outlook Web Access is functioning correctly
Test-PopConnectivity Tests the POP3 service for correct functionality
Test-ReplicationHealth Tests the health of storage group replication
Test-SenderId Tests the Sender ID process
Test-ServiceHealth Tests that all required services have started successfully
Test-SystemHealth Tests the overall configuration of your Exchange organization
Test-UMConnectivity Tests the operation of a Unified Messaging server
Test-WebServicesConnectivity Tests the functionality of Outlook Anywhere

Table 1: List of Test Cmdlets


Let’s start off with a nice easy one, the Test-ServiceHealth cmdlet.  With the new roles present in Exchange 2007, one thing that has changed over legacy versions of Exchange is that each Exchange server will now have different services configured on it, depending on the roles that it has to perform.  For example, the Microsoft Exchange Transport service will only be seen on transport servers such as those Exchange 2007 servers running the Hub Transport or Edge Transport role.  As a quick way of testing whether the required services are present and, more importantly started, you can use the Test-ServiceHealth cmdlet.

You can run the Test-ServiceHealth cmdlet on the local server to test locally installed services, or you can use the –Server parameter to target a remote server.  In Figure 1, you can see the results of running this cmdlet on an Exchange 2007 server that has the Mailbox, Hub Transport and Client Access Server roles installed.  Notice how the results are separated such that the results for each role are shown.  As you can see, the key information is presented in the RequiredServicesRunning column, which obviously indicates a successful test or not.  If any required service is not running, the RequiredServicesRunning column will show False with the corresponding service name listed in the ServicesNotRunning column.

Figure 1:
Default Results of Test-ServiceHealth


Arguably one of the more confusing new areas of Exchange 2007 is the configuration of the Autodiscover service, particularly the area surrounding certificate names.  If the wrong Subject Alternate Names are listed in the certificates or certain configuration areas not completed via other Exchange Management Shell cmdlets, the Autodiscover process will fail.  Ultimately for Outlook 2007 users this means that services such as the Offline Address Book will not be available.  Fortunately, the Autodiscover configuration can be tested using the Test-OutlookWebServices cmdlet.  Since the Autodiscover service runs on the Client Access Server role, it follows that this cmdlet is run against a Client Access Server.

The main parameter to supply with this cmdlet is the –Identity parameter which is used to test the Outlook provider and takes the form of an email address within the forest.  Take the example shown in Figure 2 where the results of the Test-OutlookWebServices cmdlet have been piped into the format-list cmdlet.  The cmdlet used was:

Test-OutlookWebServices –Identity [email protected] | fl

Figure 2:
Test-OutlookWebServices Output

What you will notice from the above results is that the AS (Availability Service), OAB (Offline Address Book) and UM (Unified Messaging) services have been successfully contacted using the EXCH Outlook provider using the local server’s Fully Qualified Domain Name (FQDN) but that the same services are not configured for the user via the EXPR Outlook provider.  This is revealed by the wording shown in Figure 3.

Id      : 1015
Type    : Information
Message : [EXPR]-The OAB is not configured for this user.

Figure 3: Missing EXPR Outlook Provider Configuration

These results are a sign that some configuration elements have not been completed.  To confirm this is the case, the Get-WebServicesVirtualDirectory, Get-OabVirtualDirectory and Get-UMVirtualDirectory cmdlets can be run and the output examined, where it should be seen that the –ExternalUrl parameter is blank.  For example, look at Figure 4 where the Get-OabVirtualDirectory cmdlet has been run with the results piped to the format-list cmdlet and filtered to only show the ExternalUrl parameter.

Figure 4:
Get-OabVirtualDirectory Output

The –ExternalUrl parameter controls the URL that Outlook uses to retrieve the OAB when running on an external network or when non-domain joined.  Conversely, on the internal network, Outlook will retrieve the OAB via the –InternalUrl parameter which, by default, will be set to the FQDN of the Client Access Server.  However, you will need to manually configure the –ExternalUrl parameter which in this example would be set to something like https://autodiscover.neilhobson.com/oab. I’m not going to discuss at length the Autodiscover service here since that’s not the focus of this article.  The key thing that you need to take away from this article is that when you see a service described as “not configured for this user” when using the Test-OutlookWebServices parameter, it’s likely that one or more –ExternalUrl parameters are missing.  Don’t forget that there are configurations for the Availability Service, the OAB and Unified Messaging.  Therefore, there are three cmdlets to run to configure the external URL accordingly.  For example, assuming a Client Access Server name of CAS1 and an external domain name of neilhobson.com, the three configuration cmdlets would be:

Set-WebServicesVirtualDirectory –Identity “CAS1\EWS (Default Web Site)” –ExternalUrl https://autodiscover.neilhobson.com/EWS/Exchange.asmx

SetOabVirtualDirectory –Identity “CAS1\OAB (Default Web Site)” –ExternalUrl https://autodiscover.neilhobson.com/oab

Set-UMVirtualDirectory –Identity “CAS1\UnifiedMessaging (Default Web Site)” –ExternalUrl https://autodiscover.neilhobson.com/UnifiedMessaging/Service.asmx

Once these have been set you can re-run the Test-OutlookWebServices cmdlet where you should see a successful test using the EXPR Outlook provider.  A sample of the wording similar to what you’d expect to see is shown in Figure 5.

Id      : 1015
Type    : Success
Message : [EXPR]-Successfully contacted the OAB service at https://autodiscover
.neilhobson.com/ews/exchange.asmx. The elapsed time was 0 milliseconds.

Figure 5: Successful Test of EXPR Outlook Provider


So far in part one of this two-part article we’ve looked at two Test- cmdlets that you can make use of when testing the configuration and operation of your Exchange 2007 server.  Hopefully you’ve seen how cmdlets such as Test-OutlookWebServices can provide valuable insight into configuration areas that haven’t been completed.  We’ll conclude our look at these cmdlets in part two of this article.

If you would like to read the next part in this article series please go to Testing Exchange 2007 With PowerShell (Part 2).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top