Whatever causes it, orphaned sites in SharePoint can be a very painful issue to deal with. One way in which an orphaned site can occur is when a STSADM command it terminated during execution because of a drop of your remote desktop connection.
If you are working with STSADM, be sure to configure your Remote Desktop settings in order to keep disconnected sessions alive. Failure to do so, WILL cause problems for you in the future.
The toughest orphaned site I’ve ever had to deal with occurred during such a case. The site was being restored from a STSADM backup. The server’s Remote Desktop settings were not set to keep the session alive and when a blip in the wireless network cause the connection to be broken, Windows simply killed the session causing the site collection to become orphaned. This was evident when the restore command was re-attempted:
stsadm -o restore -url http://server/site -filename site.stsadm.bak -overwrite
Which returned this puzzling message:
Another site already exists at http://server/site. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.
This is a puzzling message because… didn’t we specify the “-overwrite” switch? Why yes we did! So what is going on here? OK, OK. So the site is there and the “-overwrite” switch isn’t working. Let’s just delete the site. The following command is issued:
stsadm -o deletesite -url http://server/site
Only thing is, the site collection delete statement failed with the following error:
The system cannot find the path specified. (Exception from HRESULT: 0x80070003)
No problem you say. Just use the -force switch with the deletesite command. Doing that, the following command is issued:
stsadm -o deletesite -force -siteid 2a9fbc10-4a60-427b-8e6e-e1565d7e5796 -databaseserver sql -databasename Site_Content
Unfortunately, the response is not what you expected. This is the error returned:
Database “Site_Content” is not associated with this Web application
Of course, the message would make sense if the database was not associated with the web application, but it was. It is time for the good old orphan identification and handling swich… databaserepair We begin by identifying the orphaned content. We issue the following command:
stsadm -o databaserepair -url http://server/site -databasename Site_Content
As expected, the command dumps a bunch of orphaned content. Time to delete the corrupted content so we can restore the site again. Simply add the -deletecorruption switch thus:
stsadm -o databaserepair -url http://server/site -databasename Site_Content -deletecorruption
Once the corrupted content has been deleted, rerunning the command without the -deletecorruption switch yields a clean bill of health for our database thus:
<OrphanedObjects Count=”0″ />
Unfortunately, retrying the restore still fails by with the same “site exists” error. This is where I had the idea to detach and re-attach the database to try and clear up the issue. Two quick STSADM commands later thus:
stsadm -o deletecontentdb -url http://server/site -databasename Site_Content
and
stsadm -o addcontentdb -url http://server/site -databasename Site_Content
yielded:
Operation completed successfully.
Now retrying the restore thus:
stsadm -o restore -url http://server/site -filename site.stsadm.bak -overwrite
finally yielded the result we were looking for:
Operation completed successfully.
Hopefully this will help you get sticky orphaned sites handled quickly so you can move on to more important things!CheersC