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.

Cannot Open Mailbox in Outlook 2007

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:

	Copy Code
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:

	Copy Code
Get-MailboxDatabase | Set-MailboxDatabase -RPCClientAccessServer <FQDN of the Client Access Server>

Cannot Open Mailbox in Outlook 2003 and Exchange 2010 RTM

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.

Note:
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:

1. Click Tools > E-Mail Accounts > View or Change an Existing Account.
   
   
2. Select the account and click More Settings.
   
   
3. Click the Security tab.
   
   
4. Select the check box Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server.
   
   
5. Click OK.
   
   

E-Mail Messages Take a Long Time to Load for Outlook 2003 Clients

Event ID 106 is logged when you start the RPC Client Access service

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.

	Copy Code
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:

1. 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
   
   
2. 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:

1. 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:
   
   

   	Copy Code
   C:\>netsh winhttp show proxy Current WinHTTP proxy settings: Direct access (no proxy server)

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

4. 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
   
   
5. Restart the server, and then open the Exchange Management Console to check the status of the certificate.