Host Headers Real Basic Start, for the truely lost and stressed out

You should only read this article if the prospect of host headers makes you look like this.

I have recently had to do a lot of thinking about host headers. Normally I don't like them. If you can use port numbers you can make 10,000 web applications on IIS just using XXXX. This is more than enough and I like to give teams web applications with their own port number. Let them favorite it and I find soon there is not problem.

But I was landed with a piece of work where the CISCO firewall will only allow a limited number of ports. I hate this but it happens.

The key first step is not to panic. Don't worry if you don't understand host headers, because host headers are not very well understood by anyone. Host headers are essentially a technology that allows you to extend a port. Normally you have one web application on a port. For example say your have a server at IP 10.0.0.10. You can put a web application on a port. Say you have 10.0.0.10:2000. Using ports you can add thousands of web applications on a IP address. So its like have thousands of servers with their own unique IP.

You can further load an IP by adding a host header. Say I want to add a host header to a URL test.my.host.header.com. I want everyone in my network to be able to access this URL. And I need it to be on port 80. When everything is finished the IP will be 10.0.0.10:80 with host header test.my.host.header.com and users will be able to access it on your network by typing http://test.my.host.header.com.

But you have to get network exports involved. And they will have developed their own way of managing host headers, you hope. The key thing to keep in mind is that you can't do this with SharePoint alone, so don't panic.

When you can't assign a new port number to each web application you need to load all your web applications on a single port, usually port 80. Whatever you do please don't take the easy way out and build one web application on 80 and put all the site collections under it. This is grow on you and almost always go beyond the ideal 80GB of storage per content database.



What you can do is when you create a web application you can assign a host header. The problem is that when you create a site with a host header you then can't see the URL from a web browser. IIS has a web application for the host header, but your network can not resolve the request.




This is the point where I have to be kind of lame and tell you that you need to contact you network administrators. This is not to get out of the issue, but it is because different infrastructures will use different technology to resolve this. Remember that when dealing with host headers you need to work with your network team, don't pressure yourself to do it all yourself.

I can tell you one way to do it. Get a hold of who ever manages you GSS and tell them you need a URL for your SharePoint server. When they create one for you then use DNS to create an alias mapping you host header to this URL that GSS gives you. But you will need to check this with your network administrator.

What I can tell you is my opinion. I don't think its a good idea to create a site with the host header first. The problem is you can not see the site until all the administration work is done and in a large estate this could take days if not weeks. If the site looks wrong you will have to then restart building the web application with the host headers.

Rather I would first create a web application with a port number. You can test this on your server to be sure that it works. Once you have tested the server on its port you can create a new web application with a host header. Then extend the site you created to the new site with a host header and raise your request with networks or who ever else manages network traffic.

Here is a link that explains how to do this.


Ideally you should look something like this now

The outcome, worried about Host Headers but silently confident

In closing I would invite you to talk to your network people about not blocking ports and not using host headers. I have worked with a large SharePoint that did this and it worked great.

Host Headers in MOSS 2007

I was going to post something about host headers in WSS 3. Thinking about it some I guess host headers with wild card is a cool technology that allows you to publish URLs from WSS administration tool, but I can't really see a reason to do this.

My own take on URLs is as follows. WSS Web Sites should be created with IPs and ports of the form http://site:port. You should use DNS mapping to connect the http://site:port to a URL. Why not do this in SharePont? Because I think it defeats the entire purpose of a Enterprise stack. You should be mapping all URL redirects in one place, in the DNS mappings on Windows Server. Why? Because when you want to change a URL or put another site on an existing URL you should be able to do this from one spot, for all HTTP and HTTPS delivered sites.

The entire point of having tiers is to keep all your functions of one kind in one area. For example when I was designing N-tier web sites I often came across the business logic in the application or database layer. I think that looking at this as a technical performance question in most issues is wrong. What I always believed is that you should use the same layer for all or none. I always hated working with a mixture of application business logic in ASP.NET AND TSQL. It is my strong belief that you should do it all on one level or another.

So if you use DNS to manage all your SharePoint sites you can easily change the redirect for a URL to another IP and port. You can also have one area with one expert to manage ALL your URLS running all your Enterprise technology.

The principle as I see it is grouping by function.