Orphaned Host Header Site Collections
Heads up for those using STSadm to backup and restore host header site collections.
Be aware of the possibility of host header site collections becoming orphaned after you detact and reattach their content database (the content Db that contains STSADM restored hostheader site collections).
The problem begins when using an stsadm backup of one host header site collection and using the "STSADM -o restore" process to restore that backup to another hostheader site colleciton.
For example:
- you have a host header site collection called hhsitecollection1.contoso.com
- you use stsadm to backup that site collection
stsadm -o backup -url hhsitecollection1.contoso.com -filename c:\hhsitecollection1.bak
- You then take that backup and restore it to another hostheader site collection called hhsitecollection2.contoso.com that you alread have running in your farm
stsadm -o restore -url hhsitecollection2.contoso.com -filename c:\hhsitecollection1.bak -overwrite -hhurl https://<URLofHostHeaderWebApp>
What you end of with is a site collection that has the Path value "hhsitecollection2.contoso.com" still registered in the SiteMap table of the Configuration database
==========================================================================================================
===========================================================================================================
But has a HostHeader value of "hhsitecollection1.contoso.com" in the Sites table of its content database.
================================================================
| Id | HostHeader |
| BE18A48E-5DF9-428B-AD3D-AE3FE064C457 | hhsitecollection1.contoso.com |
================================================================
Note that Site's ID remains the same BE18A48E-5DF9-428B-AD3D-AE3FE064C457 in both Dbs
At this point, as long as that contentDb is never detached and reattached, you will never notice a problem as users and tools will still be able to access that site collection using the https://hhsitecollection2.contoso.com URL as they always have.
However major problems will occur once that site collection's contentDb is detached and reattached to the farm.
When that happens,one of two bad things will occur:
1) The site collection is no longer available using its original URL
For example, if an entry for "hhsitecollection1.contoso.com" does not already exist in the SiteMap table of the Configuration Database, once the contentDb is re-attached, Sharepoint will pick up the HostHeader value for the site collection from the contentDb,which is now hhsitecollection1.contoso.com due to the stsadm restore process, and enter it into the SiteMap table (along with other information such as SiteID etc.)
At this point hhsitecollection2.contoso.com will no longer be accessible via the https://hhsitecollection2.contoso.com URL.
The only accessible URL for hhsitecollection2.contoso.com will be https://hhsitecollection1.contoso.com
Fortunately at this point you can correct the problem by running
stsadm -o renamesite -oldurl https://hhsitecollection1.contoso.com -newurl https://hhsitecollection2.contoso.com
This will reset both the Path value in SiteMap table of ConfigDb and the HostHeader value in Sites table of ContentDb back to hhsitecollection2.contoso.com
and users are back on this site using https://hhsitecollection2.contoso.com
OR 2) The host header site collection becomes orphaned (it exists in the content Db but is no longer accessible)
For example this happens if a Path value of "hhsitecollection1.contoso.com" already exist in the SiteMap table of the Configuration Database,(because that site collection happens to exist in some other contentDb).
Since Sharepoint doesn't allow duplicate Path values in the SiteMap table of the Configuration Database (for obvious reasons), at this point once the contentDb is reattached to the farm, the https://hhsitecollection2.contoso.com hostheader site collection (which has hostheader value "hhsitecollection1.contoso.com" after stsadm -o restore) will become orphaned.
It still exists in the content Db but it is no longer accessible via the browser, stsadm, or SP object model)
Recovering orphaned host header site collections
One of the options for recovering these specific types of orphaned host header site collections is:
1. use stsadm - o renamesite to temporarily rename the conflicting host header site collection that is in the farm
In our example we would need to rename the good/working https://hhsitecollection1.contoso.com to a temporary name
NOTE: This will take this site out of commission until the rest of the steps are completed
stsadm -o renamesite -oldurl https://hhsitecollection1.contoso.com -newurl https://temphhsitecollection1.contoso.com
2. Detach and reattach the contentDb that contains the orphaned https://hhsitecollection1.contoso.com
(Remember its original name was https://hhsitecollection2.contoso.com before the stsadm -o restore and we need to get it back as https://hhsitecollection2.contoso.com )
So once you reattach its contentDb, https://hhsitecollection2.contoso.com is now accessible again as https://hhsitecollection1.contoso.com
3. Rename hhsitecollection2.contoso.com back to its original name
stsadm -o renamesite -oldurl https://hhsitecollection1.contoso.com -newurl https://temphhsitecollection2.contoso.com
4. Now rename the original hhsitecollection1.contoso.com (that you renamed in step 1) back to its original name
stsadm -o renamesite -oldurl https://temphhsitecollection1.contoso.com -newurl https://hhsitecollection1.contoso.com
At this point https://hhsitecollection2.contoso.com and https://hhsitecollection2.contoso.com should both be available again.
Now how to prevent this problem from occurring in the first place:
Whenever you restore a host header site collection using stsadm, just be sure to run stsadm -o renamesite immediately after the stsadm -o restore process completes.
When doing so, the -oldurl and -newurl parameters you specifiy should both be the hh site collection name that you want to use.
For example:
stsadm -o restore -url hhsitecollection2.contoso.com -filename c:\hhsitecollection1.bak -overwrite -hhurl https://<URLofHostHeaderWebApp>
then once that completes run,
stsadm -o renamesite -oldurl https://hhsitecollection2.contoso.com -newurl https://hhsitecollection2.contoso.com
This will rewrite the hostheader value in the contentDb to the -url value that you specified in the stsadm restore command (in this case hhsitecollection2.contoso.com)
======================================================================================================================
Also on a somewhat related note:
Service Pack 2 for WSS3.0/MOSS introduces the ability to "delete" orphaned site collections by using the new siteid parameter.
C:\>stsadm -help deletesite
stsadm.exe -o deletesite
[-url <url>
-deleteadaccounts <true/false>]
[-force
-siteid <site id>
-databasename <database name>
-databaseserver <database server name>]
Since your dealing with an orphaned site collection the only way to get the siteId is by looking in its content database and getting the "Id" value of the orphaned site collection
In testing I've performed, an orphaned hostheader site collection did not block or cause an SP2 upgrade to fail.
In my testing, both the Farm, and the contentDb I had that contained an orphaned hostheader site collection and was attached to the farm, upgraded successfully.
===============================================================================================================
Providing an update regarding a fix in the June 09 CU that prevents duplication of host header values that are caused when using stsadm to restore host header site collections
Problem
When restoring a host header site collection from backup to a new host header site collection, the host header value for the restored site collection is still the old sites host header. After restoring the site collection if we detach and reattach the restored site collection's content DB, the restored site collection is no longer accessible and left orphan.
Resolution
Microsoft has produced a hotfix (KB970946) to address this issue. Details of how and where to obtain the hotfix are shown below.
Related Knowledge Base Articles
The details of the hotfix can be found in the following article:
Please note that this fix can also be applied by installing the June Server-Package for WSS 3.0. This fix is detailed in the following article:
Additional Information and Recommendations
There is a link on each of the hotfix articles that will allow you to download the hotfixes when you are ready. You can also find detailed, step-by-step instructions for downloading hotfixes by clicking here.
For complete guidance on applying updates please refer to Updates Resource Center for SharePoint Products and Technologies.
Update Steps & Suggestions
To get your SharePoint installation as up-to-date as possible, we recommend that customers install updates in the following sequence (the steps below assume MOSS is installed, if it is not feel free to omit those fixes):
1. Windows SharePoint Services 3.0 Service Pack 2 (SP2)
2. The 2007 Microsoft Office Servers Service Pack 2 (SP2)
After applying the preceding updates on all servers in the farm, run the SharePoint Products and Technologies Configuration Wizard or the “psconfig –cmd upgrade –inplace b2b -wait” command on each server one at a time. This needs to be done on every server in the farm with SharePoint installed.