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 "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/"
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 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
[email protected]. 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 191.168.1.14 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 191.168.1.14 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 3.0.0.0
Date: 2/15/2011 2:38:14 PM
Event ID: 3
Task Category: WebHost
Level: Error
Keywords: Classic
User: SYSTEM
Computer: Exchange.corp.tld.com
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.