Thursday, February 17, 2011

Unknown 500 Autodiscover and RPC errors when publishing Exchange 2010 on a non-default web site

Typically, when I am implementing Exchange for a customer, I try to make the configuration as simple as possible.  Sometimes this is not always possible, unfortunately.   This particular customer had an AD FQDN that was a three letter domain name, ending in .com, that they did not own on the Internet, therefor the chances of getting a 3rd party trusted SSL certificate issued for that domain name was not possible.

Below is a diagram of the intended design and configuration of the environment (for simplicity in this post, this is a single server environment, running MBX, CAS, and HT roles on a Windows 2008 R2 Enterprise OS with Exchange 2010 Standard SP1 RU2.

So in IIS, I configured the "External Web Site" to listen explicitly on .14, and the Default listens on .13.
The default web site is protected with an internal CA, and the external with a Digicert UCC certificate.

Once this was configured, I then essentially got Exchange to use it, recreating each vDir:
  • New-AutodiscoverVirtualDirectory  -Website "External" -externalURL "
  • New-EcpVirtualDirectory  -Website "External" -externalURL ""
  • New-WebServicesVirtualDirectory  -Website "External" -externalURL ""
  • New-OWAVirtualDirectory -Website "External" -externalURL ""
  • New-OABVirtualDirectory  -Website "External" -externalURL ""
  • New-ActivesyncVirtualDirectory  -Website "External" -externalURL ""
Finally - the trickiest one is the RPC and RPCWithCert vdir's - I have blogged on that before here and the process still works. So at this point, your IIS console should look like this:

If you notice I removed the Autodiscover vdir on the default web site, it was because LAN users will use SCP and AD to autodiscover.  But otherwise, I have all Exchange vdir's duplicated.

Once this was complete, I had a network engineer create a NAT for me, and an ACL for TCP/443 to my Exchange 2010 CAS server.  I tied the DNS name to the IP of that NAT entry.  Of course, a CNAME for was also created, and my Digicert SSL cert has this name on it as a Subject Alternate Name (SAN)

Then, it was time to head over to the ExRCA tool for some CAS testing!

Unfortunately, I was immediately confronted with odd errors while autodiscovering:
ExRCA is attempting to retrieve an XML Autodiscover response from URL for user  ExRCA failed to obtain an Autodiscover XML response.
An HTTP 500 response was returned from Unknown.

From Outlook 2010: 
Autodiscover to Failed (0x80004005)

Running test-OutlookConnectivity against the External Site got this clue: 
Test-OutlookConnectivity:  An unexpected exception occurred while pinging RpcProxy. The most common reason for this occurring is that the IIS DefaultAppPool isn't running. Exception: The remote server returned an error: (500) Internal Server Error.

From the W3SVC2 IIS logs (specific to External site) 
2011-02-15 20:32:57 POST /AutoDiscover/AutoDiscover.xml - 443 - Microsoft+Office/12.0+( 500 0 0 281 
2011-02-15 20:32:57 POST /AutoDiscover/AutoDiscover.xml - 443 - Microsoft+Office/12.0+( 500 0 0 78 

Checking the application event log, I found this: 
Log Name:      Application
Source:        System.ServiceModel
Date:          2/15/2011 2:38:14 PM
Event ID:      3
Task Category: WebHost
Level:         Error
Keywords:      Classic
User:          SYSTEM
Description: WebHost failed to process a request.  Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/35104124  Exception: System.ServiceModel.ServiceActivationException: The service '/Autodiscover/AutoDiscover.xml' cannot be activated due to an exception during compilation.  The exception message is: Could not find a base address that matches scheme http for the endpoint with binding CustomBinding. Registered base address schemes are [https].. --->
System.InvalidOperationException: Could not find a base address that matches scheme http for the endpoint with binding CustomBinding. Registered base address schemes are [https].

Process Name: w3wp
Process ID: 5828

 Very Weird.  But the application event log gave the biggest hint with this:
Could not find a base address that matches scheme http for the endpoint with binding CustomBinding. Registered base address schemes are [https]."  

The fix, after a long time researching and trying different things…
Add an http listener for port 80 to the "External" Site. 

I have no idea why this works.  But it does.  That IP does not have port 80 open on the firewall, and while it is working, the IIS logs do NOT show any port 80 traffic coming into it, but without port 80 listening on the site, there are 500 unknown errors on the ExRCA for autodiscover as well the the RPC virtual directories if performing a manually configured test (bypassing autodiscover)

I am not sure if this is a bug, or a known configuration requirement, but I was unable to find any documentation from MSFT on this.


Jon Richter said...
This comment has been removed by a blog administrator.
Jon Richter said...

you might not know, but true, true. you can use any host_header for the http:80 binding

seyid said...

yu're the guy i should know before get drowned...
your post and links made me survived..

Taz said...

This is really good just what I was looking for. How did you re-create the powershell and powershell proxy apps? Same was as RPC RPCWithCert?

Taz said...

Thank you just what I was after. How did you recreate the aspnet_client folder?
Were the powershell/powershell-proxy folders created in the same fashion as we re-created the Rpc and RpcWithCert folders?

Vadim Yakovlev said...

Good post, thanks. In my environment, I ended up with same configutation - two virtual autodiscover directories, one for internal purpose and one for external, and ran into same issue - 500 error when testing Autodiscover service. Your post was very helpful, and adding HTTP binding for external site solved the problem.
However, I went further and found the root reason: that's in web.config file in Autodiscover directory. Locate in that file XML element , it contains elements, each of which contain elements. Delete 2 elements with "name=http", and then Autodiscover works even if IIS web site has only HTTPS binding!

Sean McClellan said...

Just wanted to include that I also had to do this for autodiscover to work properly. That binding to 80 isn't included by default, but sure was needed for it to work correctly.

Nuno Araújo said...

You are my savior! Awesome post!
Thank you!

Nuno Araújo said...

You are my savior!! Thanks!