I've run into this set of questions about 5 times in the past week alone, so I figure it's worth a blog entry...
Exchange setup on a standalone (non-clustered) server creates entries an HTTP protocol entry -- at approximately this location: CN=<theVS#>,CN=HTTP,CN=Protocols,CN=<yourEVSname>,CN=<yourAGname>,CN=Administrative Groups,CN=<yourORGname>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<yourDOMAINname>. The VS# at the front of the DN will be “CN=1” for the Default “Exchange Virtual Server” you find in ESM. This means that it's associated with the “Default Website” virtual server you find in IIS Administrator. It also means that since it's created essentially as a guest in the existing Default Website, it doesn't REALLY get to take over the entire virtual server -- only a very few things can be configured through the ESM GUI. For most things, you'll need to go into IIS Administrator, and the ESM GUI tells you as much.
So, here's where it gets a little different: If you're using an HTTP protocol virtual server that does NOT live within the Default Website IIS object (ie, one identified by a VS# of CN=100, CN=101, etc), then suddenly many of the configuration options must be set from within ESM rather than through IIS Administrator. If you set them in IIS Administrator instead of ESM, they will be OVERWRITTEN by the DS2MB metabase replication process (ie, you'll lose your SSL settings each time you reboot or failover!). This applies both to any additional HTTP protocol virtual servers you create in the ESM GUI, and also to the default HTTP protocol virtual server created for each clustered EVS. For the clustered case, this happens because we need to be able to replicate the protocol virtual server configuration in-full to all Exchange nodes in the cluster -- something that would likely be a bit difficult with the built-in “Default Website“.
If you pull up properties in ESM on a secondary (non-default) HTTP protocol virtual server, you will see that you have many additional configuration options not present when viewing the “Exchange Virtual Server” object through ESM. Focus on the fact that on the General tab, you can now set the IP Address bindings. That's where we're going next.
Specific IP Address bindings for each HTTP protocol virtual server can be found under the Advanced button on the General tab of properties of said protocol virtual server. In the “Advanced” dialog that comes up, you'll see a list of all “Identities” (or bindings) associated with this protocol virtual server. This is where you'd configure specific IP addresses to listen on, host headers, and ports.
Fun Fact: Since each clustered protocol virtual server will be bound to the IP address you've assigned to the EVS (rather than to “all unassigned”), there's probably no need to put in a host header -- it'll be sufficiently unique with just the IP and TCP port combination. In Exchange 2000, creating the EVS also set a host header for the netbios name of the EVS. In Exchange 2003, that's gone. Now we only set the IP and port, because host header is not required. That's a bit of a digression though, because it only applies to the “TCP Port” entry. SSL cannot use host headers, and it will not let you enter one.
Second Fun Fact: You can enter only one port per “Identification” line. I see this trip people up a lot -- the SSL port field will appear greyed out when they try to add or modify a new identity. This is quite likely because there is already something entered into the “TCP Port“ field, and the SSL Port field won't let you enter anything unless a TCP port is not already defined in the same “Identification“. What does this mean? It means that if you want both TCP Port 80 for HTTP and SSL Port 443 for HTTPS, you will need to create two separate identities under the HTTP protocol virtual server's Advanced button.
Now, for Evan's recommended way to configure bindings and SSL clustered HTTP protocol virtual servers: 1) Create new HTTP Protocol virtual server in ESM. 2) Under Advanced Tab, ensure TCP Port 80 is defined along with the EVS IP address. No host header needed. Click Ok.
Note: Now the msExchServerBindings attribute is set on the protocol virtual server object in the AD and will replicate into the IIS Metabase via the DS2MB metabase replication process.
3) Get a certificate for the protocol virtual server and install it through IIS Administrator interface. See KB.3202914) Back in ESM, click Add to add an additional identity. Remove TCP port 80 from the GUI.5) SSL Port field becomes available for entry once TCP field is cleared.6) Enter 443 into SSL port field. Click OK.
Note: Now the msExchSecureBindings attribute is also set on the protocol virtual server object in the AD and will replicate into the IIS Metabase via the DS2MB metabase replication process.
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:
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?
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.
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.
PingBack from http://www.keyongtech.com/1023788-owa-ssl-port-disappearing