Troubleshooting Exchange Server 2010 : Troubleshooting Client Connectivity (part 2)

2. Test-*Connectivity Cmdlets

One of the most fundamental changes in Exchange Server 2010 sees the final shift of mailbox access away from the Mailbox server role over to the Client Access server role. Of course, Exchange ActiveSync and Outlook Web App clients also access the Client Access server, which means that your Client Access servers are even more critical to an Exchange environment than in the past. In other words, you need to make sure your clients can access the Client Access servers in all situations. Microsoft has long recommended that you deploy at least two Client Access servers in every site that houses a Mailbox server to ensure full redundancy. This recommendation assumes that your site definitions correctly include all appropriate subnets, that your servers' IP addresses are correctly configured, and that all DNS records are properly registered in the appropriate zones.

If your client can access Autodiscover, you know that you can connect to at least one Client Access server, but it's possible to access one service on a Client Access system but not others. How can you tell if other necessary components on the Client Access server are functioning properly? Earlier we talked about two very useful cmdlets—Test-SystemHealth and Test-ServiceHealth—that can help diagnose general issues on a server. However, sometimes you can take a more surgical approach and focus on one protocol. For this, we'll use a series of cmdlets called Test-*Connectivity (where * is the protocol or client you're testing).

Figure 3. Results of an ActiveSync Autodiscover test

Depending on the client you're testing, you'll want to use one of the following cmdlets:

• Test-ActiveSyncConnectivity

• Test-OutlookConnectivity

• Test-PopConnectivity

• Test-ImapConnectivity

• Test-OwaConnectivity

• Test-WebServicesConnectivity

Most of the cmdlets above are all pretty self-explanatory; they correspond to the most popular connectivity models (although it's important to note that the cmdlets to test POP3 and IMAP4 connectivity don't include the version numbers for the protocols—it's just POP and IMAP). The Test-OutlookConnectivity cmdlet (shown in Figure 4) covers both MAPI and Outlook Anywhere connectivity, so you don't need separate ones (although as you've seen, there is also a separate Test-MapiConnectivity cmdlet).

Figure 4. Example of Test-OutlookConnectivity

The cmdlets Test-WebServicesConnectivity (shown in Figure 5) and Test-OutlookWebServices have a lot of overlap, and the essential difference is that the former checks only the web services.

Figure 5. Using Test-WebServicesConnectivity

The Test-OutlookWebServices cmdlet tests all the web services that the clients might use during normal client activity such as Autodiscover, Availability Service, and Offline Address Book. It's primarily used to troubleshoot Outlook Anywhere clients (for obvious reasons), but is still useful in other environments. Prior to running the cmdlet, though, you should run the New-TestCasConnectivityUser.ps1 script to create test users for your CAS server or servers.

The suite of cmdlets listed here provides comprehensive coverage for connectivity issues. If you can run these successfully but still can't connect your client, there's a good chance that the problem isn't with Exchange at all.

Client connectivity is a complex and involved process, and the number of troubleshooting tools reflects this. Outlook includes some basic tools, including the Test E-mail AutoConfiguration option, but for more detailed troubleshooting you'll probably need to use one of the incredibly useful Test-*Connectivity cmdlets. For external connections, you have the added luxury of the Exchange Remote Connectivity Analyzer (www.testexchangeconnectivity.com). You can also test the other services provided by Client Access servers with the Test-OutlookWebServices cmdlet. Taken as a group, these tools should allow you to quickly determine whether client connectivity problems are caused by the Exchange infrastructure.