SSL on non-default HTTP protocol virtual servers

Take Outs: The Digital Doggy Bag of Blog Bits for 25 February 2004

Enjoy Every Sandwich — Thu, 26 Feb 2004 07:23:00 GMT

In the bag tonight: Less bitch'n and whin'n. Counts:Blogging: 8; Dev: 22; Otherwise: 8; SQL: 5; WILY: 8. Line of the night:

re: SSL on non-default HTTP protocol virtual servers

walnut — Sun, 23 May 2004 03:33:00 GMT

question on this:

i screwed up the default Exchange Virtual Server by electing to apply inheritance overriding during a botched attempt at including PHP scripting to my server.

now when people go to: http://ourdomain.com/exchange they see the directory index, not the pretty outlooky gui they used to see.

as a workaround, i created a second virtual server which sits outside the default website, and (as noted above [i think]) isn't configured to use SSL.

will following these instructions fix my problem (at least, will enable SSL connections over the newly created virtual website for exchange...?

if so, how do i now delete the now munged and default Exchange Virtual Server?

please help!

re: SSL on non-default HTTP protocol virtual servers

Evan — Sun, 23 May 2004 16:51:00 GMT

Walnut -

These steps may help you with the secondary protocol virtual server, but it might be more instructive to figure out why the default settings aren't working. If you're seeing the directory-index view of the virtual directory, that implies to me that the Exchange ISAPI stuff is not in place or has been overridden somehow.

I'm not 100% clear from your post whether this is a cluster or not, or whether the protocol virtual server you're talking about is the "Default Website", but let's presume that it is not a cluster and that it is the default website since that's probably the most common situation.

Easiest way to check the ISAPI config:
1) in IIS Administrator, pull up properties of the Default Website
2) Switch to ISAPI filters tab and see if "Microsoft Exchange Web Component" is listed. In a typical Exchange 2003 server, this will be the only filter listed, but if you've setup PHP, etc... there might be other filters as well that are conflicting.

This ISAPI filter should be pointing to the ExchSrvr\bin\exchfilt.dll file in whatever location it exists on your system.

3) Drill into the protocol virtual server and pull up properties on the /Exchange virtual directory.
4) On the "virtual directory" tab, "create" an application if one is not already created.
5) Click on Configuration to pull up the properties of the application
6) In Windows 2003 there is an option to configure "wildcard mappings" at the bottom of the window that opens up. Ensure that the ExchSrvr\bin\davex.dll file is listed as a wildcard mapping -- this is the component that is responsible for rendering the data in OWA, making it not look like an FTP directory interface.
7) Once you've confirmed the davex.dll file is specified, click OK to close out of the application configuration
8) If you created an application, go ahead and remove it. You don't need it -- the davex configuration will stick just fine.

Once you've fixed both of these items, it should get you past any ISAPI conflicts from PHP and generally will get OWA working for you again.

Luck!
Evan

re: Host Headers and Exchange Clusters

Evan's WebLog — Mon, 24 May 2004 17:04:00 GMT

re: SSL on non-default HTTP protocol virtual servers

Peter Suba — Thu, 05 Aug 2004 14:59:00 GMT

Just a sidenote: if You have a frontend NLB farm for OWA, please note, that ESM doe only show all available IP addresses of a particular node if you run ESM ON THAT NODE. Therefore, configure SSL on each node separately, or directly within the AD property, otherwise You won't be able to.

Peter

OWA SSL Port disappearing | keyongtech

OWA SSL Port disappearing | keyongtech — Thu, 22 Jan 2009 09:23:21 GMT

PingBack from http://www.keyongtech.com/1023788-owa-ssl-port-disappearing