Host header (actually Host Named) site collection in MOSS (some details)If you search on the web on how to create a host header (HH) site-collection you will get a lot of results as lot of community folks have written about it. Thanks to all of them for the great work. So following is the command used to create a HH site-collection is:
stsadm -o createsite -url http://THE-HOST-HEADER-FOR-THE-SITE-COLLECTION -ownerlogin DOMAIN\username -owneremail email@example.com -hhurl http://THE-URL-OF-THE-WEBAPPLICATION-THE-SITE-COLLECTION-IS-GOING-INTO
And in case if you want to create it in a new content database then following is something you can use, inspired and referred from http://sharepointhawaii.com/wenhe/Lists/Posts/Post.aspx?List=dbcd4f5c%2D63e1%2D416c%2Db34a%2Ddd391d48beab&ID=9:
stsadm -o CreateSiteInNewDB -URL http://The URL for HH site collection -owneremail firstname.lastname@example.org
-ownerlogin domain\username - -databaseserver DBServerName
I had some simple queries on some basics of the hostheader (host named) site collection and Troy Starr (from MOSS Product team) was a *BIG* help (as always) in answering my queries:
Q: how does Sharepoint handle the HH site urls (as there is no entry anywhere on the IIS) how does sharepoint know about the url to the HH site (when the url itself is different). basically I have a web-app with url: http://usctapMOSS now i create a HH site-collection with a url: http://msfturltest.abc.com and then I create a required DNS entry for that url now how does sharepoint know to redirect the "http://msfturltest.abc.com" to the correct site-collection in the http://usctapMOSS web-app.
A: When the IIS web site receives the request for _http://msfturltest.abc.com, it will pass it off to SharePoint. SharePoint will then look at the properties of the request, including its protocol scheme, host name, and port number, to determine the request URL. It will then look up that request URL in its internal table of AAM URLs and host-named site collection URLs to find a match. Once it has a match, it opens the site collection associated with that URL and goes from there. The internal table referred here is logical and by looking at the Path column in the configuration database's SiteMap table we can see the host headers assigned to individual site collections. Also note that this lookup information for the site will be cached on the WFE after the first browse.
Q: Can we restore a backup taken from a non-HH site-collection to a HH-kind of site-collection. (Both the source and target site-collection are in the same web-app and have their own Content database each).
A: In general, yes, you can back up a non-HH site collection and restore it as an HH site collection. Also, in case if this restore of a host-named site collection causes a content database corruption, we can try to fix that corruption by immediately running the stsadm -o renamesite operation after the restore and renaming the HH site URL to itself.
Thought of sharing this information in case if someone else had similar doubts.
We were working on a publishing site and had couple of custom field types and controls also as part of our custom development. We were doing Content Deployment to publish our Sharepoint 2007 (MOSS) authoring site to the Publishing site. While doing so typically we were getting following errors:
1. VALUE CANNOT BE NULL
2. Object reference not set to an instance of an object
After carefully looking at the custom developed features we found that some of the custom code was using SPCONTEXT and that code was getting executed during Content Deployment (How did we find this: We attached the owstimer.exe service on the server and ran our custom code in the debug mode).
The problem was with the code of the custom field type was relying on the usage of SPContext object and this object can only be used inside a http request to a sharepoint site. Hence it will always fail during the content deployment (as OWSTIMER.EXE will always have SPContext null) and where no SPContext object exists. We resolved this issue by checking for value of SPContext i.e. we introduced SPContext != null before executing the code and we got over that issue.
Make sure to restart the OWSTIMER service after you re-deploy the changed code. Always remember that HTTPContext will not exists while doing the Content deployment and if you have any custom code that directly relies on SPContext will tend to fail and hence the content deployment also.
Hope this helps someone.