Troubleshooting Client Connectivity

Many of us subconsciously assume that “client” means Outlook (my favorite request to this day from an overzealous business owner was “David, can you please fix our Outlook server!”), but it’s not the only client software (or device) capable of accessing Exchange Server 2013. Outlook is the most popular, but there’s also Outlook Web App and ActiveSync-enabled devices like Windows Phone, Windows RT, Google’s Android, and Apple’s iPhone. Despite the obvious differences between these devices, they all rely on the same basic mechanisms to connect—locating the Client Access server and connecting to the appropriate interface. There have been many architectural changes introduced to the Client Access server role in this release of Exchange Server, but the basic premise still applies; identify your server’s name, try to resolve its IP address, and attempt a connection to its required TCP/UDP ports.

Before troubleshooting the server components, it’s a good idea to test the following:

• Verify that the client can successfully ping the Client Access server by both IP and fully qualified domain name. If the forest includes multiple domains, ping the Client Access server by short (NetBIOS) name as well so that you can verify that NetBIOS names are being resolved correctly.
• For a mobile device, verify that the device can access Internet-based content by browsing to a known website.
• Verify the username-and-password combination for the mailbox you’re attempting to access.

If these tests fail, the problem may not be unique to Exchange Server, or if it is, it may not be unique to the Client Access role.

Troubleshooting Autodiscover

The Autodiscover service is the most important initial consideration for Outlook client connectivity. As described in Chapter 6, “Understanding the Exchange Autodiscover Process,” the Autodiscover service generates an XML file with all the appropriate user settings and sends it to Outlook, which then uses that information to connect the user to their mailbox. But how does Outlook even know where to find Autodiscover in the first place? Depending on the client’s location (on the corporate network or the Internet), the client will either check Active Directory for an appropriate record or look for a specific URL. There are a few different ways to check this, all of them very useful.

Internal Clients

Internal clients connect to Active Directory and check for the service connection point records, which are automatically published as part of the setup process. One easy way to validate Autodiscover for internal clients is with the Outlook Test E-mail AutoConfiguration tool. This useful little feature was introduced in Outlook 2007 and simply goes through the steps for Autodiscover without making changes to the current configuration. To access this wizard, start Outlook, Ctrl+right-click the Outlook icon in the notification area (system tray), and then select Test E-mail AutoConfiguration from the context menu. You can see a sample of the Test E-mail AutoConfiguration tool in Figure 24.8.

Figure 24.8 Using the Test Email Auto Configuration tool

After providing appropriate user credentials and ensuring that only the check box for Use Autodiscover is selected, click Test to begin the configuration check. The AutoConfiguration test checks for much more than just Autodiscover: it also locates Availability Service, OOF, Offline Address Book, Unified Messaging, Outlook Web App, and Exchange Control Panel URLs, making this one of the most useful client-based configuration tools.

If the AutoConfiguration test fails, the tool will display an error message. The four most common error codes, along with the most common root causes, are listed here:

0x80072EE7 – ERROR_INTERNET_NAME_NOT_RESOLVED A missing host record for the Autodiscover service in the domain naming service

0X80072F17 – ERROR_INTERNET_SEC_CERT_ERRORS An incorrect certificate configuration on the Exchange Server computer that has the Client Access server role installed

0X80072EFD – ERROR_INTERNET_CANNOT_CONNECT Issues that are related to the domain naming service

0X800C820A – E_AC_NO_SUPPORTED_SCHEMES Incorrect security settings in Outlook

Since Exchange Server 2013 requires Outlook Anywhere connectivity for both internal and external clients, the AutoConfiguration test checks the client configuration for Outlook Anywhere. When a client connectivity failure occurs, it’s important to ensure that the names used to connect to Client Access services can be resolved both internally and externally.

External Clients

If external clients can’t connect to Exchange Server, you may need to ensure that you’ve configured your environment properly for remote access to the Exchange Server organization. Here are some of the configurations you would apply into an existing organization to configure access to Outlook with the name outlook.konopizza.ca. (In each case you’ll obviously need to substitute your own domain name space.)

• To configure the external Autodiscover name for Outlook Anywhere, the appropriate command is as follows:

Enable-OutlookAnywhere -Server CAS01 -ExternalHostname "OUTLOOK.KONOPIZZA.CA" -ExternalAuthenticationMethod "Basic" -SSLOffloading:$False

• The equivalent command for Web Service clients is as follows:

Set-WebServicesVirtualDirectory -identity "CAS01\EWS (Default Web Site) " -externalurl https://OUTLOOK.KONOPIZZA.CA/EWS/Exchange.asmx -BasicAuthentication:$True

• Here’s the equivalent command for ActiveSync clients:

Set-ActiveSyncVirtualDirectory -identity "CAS01\Microsoft-Server-ActiveSync (Default Web Site) " -externalurl https://OUTLOOK.KONOPIZZA.CA/Microsoft-Server-ActiveSync

• And here’s the equivalent command for the Offline Address Book:

Set-OABVirtualDirectory -identity "CAS01\OAB (Default Web Site) " -OUTLOOK.KONOPIZZA.CA/oab

If you are in the process of configuring your organization for remote access, there is a great solution for troubleshooting your configurations in Exchange Server 2013: the Microsoft Remote Connectivity Analyzer (RCA). In 2008 Microsoft quietly released the beta of this extremely useful tool, then called the Exchange Server Remote Connectivity Analyzer. It simulates a number of connectivity scenarios, including Autodiscover, Exchange ActiveSync, Outlook Anywhere, and incoming Internet SMTP email. To use the RCA, simply browse to www.testexchangeconnectivity.com and select the appropriate option (see Figure 24.9).

Figure 24.9 The main page of the Remote Connectivity Analyzer web page

Today this tool provides assistance to administrators who have hybrid environments with Office 365 and even coexistence with other technologies such as Lync Server 2013.

Using the Test-* Connectivity Cmdlets

Microsoft has long recommended that to ensure full redundancy you deploy at least two Client Access servers in every site that houses a Mailbox server. 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. However, Exchange Server 2013’s changes in role management have meant that Microsoft now recommends that each Exchange server have both roles installed. Based on this new math, you can expect that a one-to-one mapping of Mailbox servers and Client Access servers will be sufficient.

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).

Troubleshooting Using Cmdlets

You’ve probably noticed that troubleshooting Exchange Server 2013 involves a lot of cmdlets, and you’re right! The Exchange Server product group worked hard to ensure that administrators had easy-to-use, robust, focused troubleshooting tools right at their fingertips, and the resulting family of cmdlets serves as a testament to those efforts.

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

• Test-ActiveSyncConnectivity
• Test-ImapConnectivity
• Test-OwaConnectivity
• Test-PopConnectivity
• Test-WebServicesConnectivity

These cmdlets 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 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 Server at all.