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 "https://mail.company.com/Autodiscover/autodiscover.xml
- New-EcpVirtualDirectory -Website "External" -externalURL "https://mail.company.com/ecp"
- New-WebServicesVirtualDirectory -Website "External" -externalURL "https://mail.company.com/ews/Exchange.asmx"
- New-OWAVirtualDirectory -Website "External" -externalURL "https://mail.company.com/owa"
- New-OABVirtualDirectory -Website "External" -externalURL "https://mail.company.com/OAB"
- New-ActivesyncVirtualDirectory -Website "External" -externalURL "https://mail.company.com/Microsoft-Server-Activesync/"
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 mail.company.com DNS name to the IP of that NAT entry. Of course, a CNAME for autodiscover.company.com 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 https://autodiscover.company.com/AutoDiscover/AutoDiscover.xml for user firstname.lastname@example.org. ExRCA failed to obtain an Autodiscover XML response.
An HTTP 500 response was returned from Unknown.
From Outlook 2010:
Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xmI 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 126.96.36.199 POST /AutoDiscover/AutoDiscover.xml - 443 - xx.xxx.xx.xx Microsoft+Office/12.0+(TestExchangeConnectivity.com) 500 0 0 281
2011-02-15 20:32:57 188.8.131.52 POST /AutoDiscover/AutoDiscover.xml - 443 - xx.xxx.xx.xx Microsoft+Office/12.0+(TestExchangeConnectivity.com) 500 0 0 78
Checking the application event log, I found this:
Log Name: Application
Source: System.ServiceModel 184.108.40.206
Date: 2/15/2011 2:38:14 PM
Event ID: 3
Task Category: WebHost
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.
you might not know, but true, true. you can use any host_header for the http:80 binding
yu're the guy i should know before get drowned...
your post and links made me survived..
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?
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?
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!
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.
You are my savior! Awesome post!
You are my savior!! Thanks!
Post a Comment