Evan Dodds - Microsoft Exchange Server Blog

Exchange, Exchange administration stuff, and other assorted ramblings

Blogs

Host Headers and Exchange Clusters

  • Comments 5
  • Likes

Here's another topic that seems to come up on a fairly regular basis: how and when to use host-headers with Exchange HTTP protocol virtual servers.

Host headers are a great invention: they let you bind an IIS protocol virtual server directly to the unique combination of IP address, TCP port, and the host header -- the host portion of the URL sent from the client-browser. This lets you host multiple protocol virtual servers bound to a single IP address and port combinations. The client (any recent web browser) sends this host header along with the HTTP request, so IIS can figure out which protocol virtual server to direct the request to. In general, the host header simply makes a protocol virtual server more unique; if you don't need more uniqueness to distinguish multiple protocol virtual servers, you don't need to define a host header. Good stuff. See the W3 definition.

Updated (Feb 8, 2005) since I see a bunch of hits on this in the referrer logs: another common confusion is around SSL and host headers. The short version is: you can’t. SSL encrypts the part of the HTTP packet that contains the host headers, so by the time the IIS server would process the host header, it would already be attached to a particular virtual server and certificate. Only one SSL-enabled HTTP virtual server per IP address can be configured.

In the non-cluster Exchange case, by default you have a single HTTP protocol virtual server defined on the server -- the “Default Website“. Exchange just adds a few virtual directories to this existing virtual server, and the virtual server may well be used by other stuff as well. In this case, it's not a good idea to put a host header on the protocol virtual server. Why not? Because you have only one protocol virtual server. If you define a host header on the protocol virtual server, then any connections to the IP address (or to any other hostname/FQDN that resolves to the IP but doesn't match the host header) will not have anywhere to go -- they won't match any protocol virtual servers.

Evan's TIP #1: Never put a host header on the “Default Website“ protocol virtual server.

So, what happens if you add a second protocol virtual server in ESM? If you assign it to the same IP and port as the default website, all of a sudden you have a conflict -- both the default website and the new protocol virtual server have the same binding. But if you assign the new protocol virtual server a host header, you're in the clear. It's unique. This is a good time to use a host header -- to establish uniqueness when you've got multiple protocol virtual servers that would otherwise conflict.

If you don't need to establish uniqueness, why would you use a host header on your protocol virtual server? Well – generally you wouldn't!

In Exchange 2000 clusters, when you create the System Attendant resource, it will create all of the other Exchange resources it requires along with their configuration in the Active Directory. This will include the protocol virtual servers for HTTP, and these will have the netbios name of the EVS stamped in as host-header configuration. The most interesting thing about this configuration, however, is that these HTTP protocol virtual servers will be bound to the dedicated EVS IP address defined for Exchange. This means that there would NOT be any IP address conflict with other HTTP protocol virtual servers on the cluster node. So, although it doesn’t really HURT anything to have these host-headers in place, it also isn’t really needed. And in most cases, it makes configuring things like OWA access with FQDN and FE/BE access to the cluster EVS unnecessarily more complicated. You can remove this default host header and still provide the unique combination of IP and Port binding required to make the HTTP protocol virtual server function.

Evan's TIP #2: Never use a host header configuration if you don’t need to.

In Exchange 2003 that configuration default was changed. Since the IP address (defined within the EVS group) and Port binding (generally 80) are going to be unique within the cluster node, there’s no need to specify a host-header value. Typically, the only reason to specify a host header value is to create uniqueness where multiple EVS would otherwise overlap and conflict. Not specifying a host-header in Exchange 2003 means that we now rely on the IP address used for the HTTP protocol virtual server being sufficiently unique to distinguish it from other HTTP protocol virtual servers in the cluster. This means there’s no need to go in and augment or remove the host headers in order to make FQDN OWA access or FE/BE access to the clustered Exchange Virtual Server work correctly.

In conclusion: You may want to consider adding back in an HTTP protocol virtual server host header configuration if you add additional/multiple HTTP protocol virtual servers dependent on the same IP address, but otherwise you will find this change to the default configuration leads to easier deployment of Front-end/Back-end design in clustered Exchange scenarios.

Comments
  • And don't forget that Host Headers don't work with HTTPS (SSL) connections

  • And don't forget that Host Headers don't work with HTTPS (SSL) connections

  • Rich -

    Excellent point! I touched on that limitation briefly in this post on SSL and protocol virtual servers back in February (http://blogs.msdn.com/evand/archive/2004/02/25/79818.aspx), but it's certainly worth calling out again here.

    Evan

  • good article but problem is that to get owa working from internet you have to assign IP address unassigned to the default website. Seems this configuration is alsmos impossible when implementing clustering.

    Has anyone got any ideas??

    Ade

  • PingBack from http://www.keyongtech.com/1023668-exchange-2k3-error-with-public