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>]
           -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 



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.


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:

970946 Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Sts.msp): June 30, 2009


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:


971538 Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): June 30, 2009

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)

3. 971620 When you install the 2007 Microsoft Office servers Service Pack 2, the product expiration date is activated incorrectly

4. 971538 Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): June 30, 2009

5. 971537 Description of the SharePoint Server 2007 Cumulative Update Server Hotfix Package (MOSS server-package): June 30, 2009


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.