Exchange 2010 EWS Proxy Event ID 16: No Applicable Client Access Servers

Applies to: Exchange Server 2010

Historical: This article covers the Exchange Server 2010 Client Access Server (CAS) proxy architecture. Exchange 2013 and later use a different Client Access / proxy model, so this specific troubleshooting flow should not be applied to current Exchange Server releases.

In a multi-site Exchange 2010 environment, an Internet-facing Client Access Server could proxy Exchange Web Services (EWS) requests to a Client Access Server in the Active Directory site that hosted the mailbox.

If Exchange could not identify a suitable Client Access Server in the destination site, the Application log could contain MSExchange Web Services Event ID 16 with a message similar to:

Client Access server failed to proxy Exchange Web Services to Active Directory site because there are no applicable Client Access servers in the destination site.

In This Article

• 1. How Exchange 2010 EWS Proxying Worked
• 2. Check the Destination Site
• 3. Check the EWS Virtual Directory
• 4. Check InternalNLBBypassUrl
• 5. Check Certificate and Connectivity
• 6. About the Old AllowInternalUntrustedCerts Workaround
• 7. Key Takeaways

1. How Exchange 2010 EWS Proxying Worked

Exchange 2010 used EWS HTTP proxying when the Client Access Server receiving the request was not in the same Active Directory site as the user’s mailbox.

For an Internet-facing site, the external Client Access Server could accept the client request and proxy it to an internal Client Access Server in the mailbox site’s Active Directory site.

2. Check the Destination Site

Start by confirming that the destination Active Directory site actually contains a healthy Exchange 2010 Client Access Server that can service EWS requests.

Get-ExchangeServer | Format-Table Name,ServerRole,Site -AutoSize

Verify that:

• The expected Client Access Server is assigned to the correct Active Directory site.
• The server is online and Exchange services are healthy.
• DNS resolves the server correctly between the two sites.
• Required HTTPS connectivity is available between the Client Access Servers.

3. Check the EWS Virtual Directory

Review the EWS virtual directory configuration on the Client Access Servers:

Get-WebServicesVirtualDirectory | Format-List Identity,InternalUrl,ExternalUrl,InternalNLBBypassUrl

Confirm that the URLs resolve to the expected servers and that the destination EWS virtual directory is reachable from the Internet-facing CAS.

4. Check InternalNLBBypassUrl

In Exchange 2010, InternalNLBBypassUrl was specifically used by EWS proxy requests so that one Client Access Server could connect directly to another Client Access Server instead of sending the proxy request back through the load balancer.

If the EWS InternalUrl points to a load-balanced namespace, make sure InternalNLBBypassUrl points to the individual Client Access Server URL.

Set-WebServicesVirtualDirectory "CAS02\EWS (Default Web Site)" -InternalNLBBypassUrl https://cas02.contoso.com/ews/exchange.asmx

5. Check Certificate and Connectivity

The proxying Client Access Server must be able to establish HTTPS connectivity to the destination CAS. Check that the certificate presented by the destination server is valid for the name used in the EWS URL and is trusted by the source server.

Also verify DNS, firewall rules, TCP 443 connectivity, and IIS/EWS availability before assuming the event is caused by certificate trust alone.

6. About the Old AllowInternalUntrustedCerts Workaround

The original version of this article used an AllowInternalUntrustedCerts registry setting to bypass certificate trust checks between Client Access Servers.

I no longer recommend that approach. It was associated with older Exchange 2007-era proxy scenarios that used self-signed certificates. The better fix is to correct the certificate, namespace, EWS virtual directory, Active Directory site, and connectivity configuration rather than disabling trust validation.

7. Key Takeaways

• Event ID 16 is tied to the Exchange 2010 cross-site Client Access Server proxy architecture.
• First confirm that a suitable Client Access Server exists and is healthy in the mailbox site’s Active Directory site.
• Check the EWS InternalUrl and InternalNLBBypassUrl configuration.
• Validate DNS, HTTPS connectivity, IIS/EWS health, and certificate trust.
• Do not use AllowInternalUntrustedCerts as the permanent fix.

References

• Microsoft Learn Archive – Configuring EWS for Proxy Requests in Exchange 2010
• Microsoft Learn – Set-WebServicesVirtualDirectory