Today, I had a pretty interesting challenge. A customer had an internal FQDN that they did not own on the Internet, and could not get an SSL cert issued for their AD FQDN name on their SAN certificate. Now, I have not run into this issue in a while - the last time was on a Windows 2003 (IIS6) server - this time was a Windows 2008 (IIS7) configuration.
The actual issue of splitting the certificates is a pretty well known and well documented procedure. We used the "default web site" for internal CAS, and secured it with an Enterprise CA signed certificate. I created a "External OWA" site for external CAS, and assigned the Digicert SAN cert to that site. I should also note, the External OWA site listened on a different LAN IP that was ONLY used for the NAT entry with TCP/443 (HTTPS) enabled to it.
Using Powershell, I was able to run (not exact commands, some of these will prompt you for additional required attributes)
- New-OWAVirtualDirectory -WebSiteName "External OWA"
- New-ActivesyncVirtualDirectory -WebSiteName "External OWA"
- New-OABVirtualDirectory -WebSiteName "External OWA"
- New-WebServicesVirtualDirectory -WebSiteName "External OWA"
This got me 95% of the way to having a working CAS server. The only issue - I was missing the /rpc and /rpcwithcert directories that Outlook Anywhere and RPC over HTTPS rely upon. There is no Powershell command for this, as it's not really an Exchange component.
Now, the last time I had to splut internal/external was on Windows 2003, you would back up the virtual directory in question to an XML file, then import it on the other site. This is no longer an option in IIS7.
I also admit, I do not know IIS7 very well, and I attempted to manually recreate the directories by investigating settings and mimicking them. I got pretty close, but the Exchange Remote Connectivity Analyzer was still reporting issues.
Google and Bing really didn't turn up much (rpc, iis7, windows 2008, exchange 2007, are all pretty common search words)
I eventually found this blog entry written by Saurabh Singh related to RPC over HTTP as it related to a TS Gateway issue that he ran into.
And awesomely - it WORKED.
So opening up the applicationhost.config file, I was able to build up the virtual directories and all their settings identically on a second non-default web site. Ran an IISreset, and then re-enabled Outlook Anywhere and everything worked!
Post a Comment