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.320291
4) 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.