Troubleshooting Reference for Client Access Servers
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2012-09-24
After you've installed the Client Access server role on a computer running Microsoft Exchange Server 2010, you may have to test the functionality of the server or solve problems related to client connectivity. The following information will help you troubleshoot common errors and test to ensure that your Client Access server is configured correctly. This topic will be updated on a regular basis.
The Microsoft Exchange Remote Connectivity Analyzer (ExRCA) can help you confirm that connectivity for your Exchange servers is configured correctly and to diagnose any connectivity issues. The Remote Connectivity Analyzer Web site offers tests for Microsoft Exchange ActiveSync, Exchange Web Services, Outlook, and Internet e-mail.
For more information, see Understanding the Remote Connectivity Analyzer.
The following links and information will help you troubleshoot Outlook client connectivity.
If you can't open a user's mailbox in Microsoft Office Outlook 2007, but you can open the mailbox in Microsoft Office Outlook Web App, verify the server information by running the following command:
Get-MailboxDatabase | fl RPCClientAccessServer
If the output of that command is the name of the Exchange 2010 Mailbox server, it's likely that the Client Access server role and the Mailbox server role were installed in the incorrect order. The value of the parameter RPCClientAccessServer is set to the Mailbox server instead of the Client Access server. To resolve this issue, run the following command:
Get-MailboxDatabase | Set-MailboxDatabase -RPCClientAccessServer <FQDN of the Client Access Server>
If you're trying to access a mailbox on an Exchange 2010 Mailbox server with Office Outlook 2003, you might receive one of the following error messages:
Cannot start Microsoft Office Outlook. Unable to open the Office window. The set of folders could not be opened.
Unable to open your default e-mail folders. The information store could not be opened.
In Exchange 2010, the RPC endpoint is encrypted by default. However, Outlook 2003 doesn’t enforce encrypted MAPI connections. When you upgrade your organization to Exchange 2010, your clients that are running Outlook 2007 or later versions will automatically be compatible with the change to RPC Client Access, because they support RPC encryption by default. However, Outlook 2003 doesn’t use RPC encryption, and RPC Client Access requires it by default.
|By default, Exchange 2010 Service Pack 1 (SP1) encryption on the RPC endpoint isn't enabled. Therefore, this error shouldn't occur.|
To configure Outlook 2003 to use RPC encryption, follow these steps:
Click Tools > E-Mail Accounts > View or Change an Existing Account.
Select the account and click More Settings.
Click the Security tab.
Select the check box Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server.
UDP notification support was removed from Exchange 2010. As a result, Outlook 2003 can only use polling notifications in online mode. This will result in a slight delay in updates to item status (30 seconds on average with up to a one-minute delay) when changes are made to items in a mailbox accessed with Outlook 2003. There are two workarounds for this issue:
Use Outlook 2003 in Cached Exchange Mode.
Adjust the polling interval on the Client Access server. This will impact the performance of the Client Access server.
For more information about this issue, see E-mail messages take a long time to send and receive.
If the Microsoft Exchange RPC Client Access service is started on an Exchange 2010 Mailbox server that doesn’t have the Client Access server role installed, Event ID 106 is logged in the Application log. This error occurs because the performance counters of the RPC Client Access service aren’t installed when the Mailbox server role is installed without the Client Access server role. To resolve this error, install the Client Access server role on the Exchange 2010 server.
When a user tries to sign in to Outlook Web App, he may receive the following error message:
A server configuration change is temporarily preventing access to your account. Please close all Internet Explorer windows and try again in a few minutes. If the problem continues, contact your helpdesk.
This can happen when the DNS record of the Client Access server is modified and a user tries to sign in to Outlook Web App before the DNS cache in Internet Explorer is refreshed. This can be resolved by the user closing all browser windows to force Internet Explorer to update the DNS cache. See How Internet Explorer uses the cache for DNS host entries for information about the DNS cache in Internet Explorer.
To avoid this, create a second DNS entry for the Client Access server and use the Set-OwaVirtualDirectory cmdlet to configure the FailbackUrl parameter to match. The FailbackUrl parameter specifies the host name Outlook Web App uses to connect to the Client Access server after failback in a site resilience process and requires a separate DNS entry pointing to the original Client Access server's IP address. The FailbackUrl parameter must be different from the ExternalUrl parameter.
This example configures the FailbackUrl parameter.
Set-owavirtualdirectory -identity "owa (default web site)" -FailbackUrl "<failback URL>"
For more information about syntax and parameters, see Set-OwaVirtualDirectory.
Exchange 2010 uses Microsoft Windows HTTP Services (WinHTTP) to manage all HTTP/HTTPS traffic. Because of this, Exchange 2010 does not use the proxy server settings that may be configured in the web browser. WinHTTP uses Web Proxy Auto-Discover Protocol (WPAD), and requires that a Proxy Access Control (PAC) file be specified through DHCP or DNS.
If the WinHTTP proxy settings are configured incorrectly, the following issues may occur:
After you import a valid third-party certificate to an Exchange 2010 CAS, the EMC may report the following status: The certificate status could not be determined because the revocation check failed
If you run the Get-ExchangeCertificate cmdlet in the Exchange Management Shell, you see the following status for the imported certificate: Status : RevocationCheckFailure
To resolve these issues, follow these steps:
To list the WinHTTP proxy settings, type the following command at a command prompt, and then press Enter: netsh winhttp show proxy. The response shows the current proxy information that is being used by Exchange. Typically, you receive a response that resembles the following:
C:\>netsh winhttp show proxy Current WinHTTP proxy settings: Direct access (no proxy server)
If the correct server is not identified in the response, configure the proxy setting for WinHTTP by using the netsh command. Also, configure the server FQDN in the bypass-list so that the Exchange Management Shell and the Exchange Management Console can contact Remote PowerShell.
To do this, type the following command at a command prompt, and then press Enter: netsh winhttp set proxy proxy-server="http=<Proxy_Server_Name>" bypass-list="*.<Exchange_Server_Hostname_Domain>"
Note: Replace the <Proxy_Server_Name> placeholder by using the proxy server name. Also, replace the <Exchange_Server_Hostname_Domain> placeholder by using the second-level domain name and the first-level domain name of the Exchange Server (for example, microsoft.com)
Close and then open the Exchange Management Console. Check the status of the certificate. If the proxy settings are correct but the certificate status is still incorrect, run the following commands at a command prompt to clear the OCSP/CRL cache:
certutil -urlcache ocsp delete
certutil -urlcache crl delete
Restart the server, and then open the Exchange Management Console to check the status of the certificate.