Wednesday, June 3, 2009

Dealing with Sharepoint Orphans

Orphans are the objects in a SharePoint schema that live without a parent or child relationship in the database. The entries that made in the config DB are incomplete or missing some thing.
Reasons for the Orphans creation:

  1. Usually orphans get createed while migrating the sites from SPS 2003 to MOSS.
  2. User creating the site, doesnt have enough permissions on the DB.
  3. User closing the site creation module abruptly.

Symptoms:
Usually, orphaned sites will not be available to view from the browser. In some cases I saw some orphaned sites that look fine from the browser, but breakes the lists and sub sites eventually.
There is no UI module in the CA or any site settins page available to detect an orphan. Orphans can only be detected through SQL or below STSADM command.

stsadm -o databaserepair -url -databasename [-deletecorruption]

The above STSADM command is for MOSS orphans that exist in the configDB.
Use the below SPSADM command to remove the orphans in the SPS 2003.

spsadm repairorphans portalURI.

Some orphans are very adamant and needs the manual removal. Below is the explaination and fix for each kind of orphan.

Types or orphans:
1. Configuration Orphans: These orphans are very easy to deal with, as these orphans could only mess up your configuration DB. Possibly, they do not have a content DB entry for a child. Detaching the corrputed content database from your farm and reattach it would fix the issue. This is a kind of config DB flush that would refresh the sitelist that is tied to that content database and removes the wrong entry automatically.
2 . Content Database Orphans: These are bit complex to deal with.
There are 2 essential types of content database orphans.

Type 1 Scenario(reactive maintenance):

Site content is is available in the farm's content database but not mapped to the proper configuration . In this kind of scenario, a blank new site is mapped to the configuration database.
So, the symptom is, whenever you access a site you always endup viewing a blank site.
Fix:
> Backup the orphaned site .
> Delete the orphaned site.
> Detach and reattach the database that contains the site's content.
This fix will edit/remap the site to the configuration database.
Type 2 Scenario(Planned Maintenance):

Site mapping is good, all the sites are rendered properly. But you see orphans in a content database or other databases.
Fix:
Backup your production site and delete it. Once that completes detach and attach the database that contains orphan, this will in effect map the orphan to the configuration database and render it accessible. You can then delete it using STSADM. Perform these steps until you have cleaned all orphans. Once all orphans are clean you can then restore your production site back into the farm.

The above fixes are good for any terrific orphans legally. When I say legally, by the means of following the Microsoft's headsup. As an extra information, I experimented on deleting the site intries and re-mapping in a very low level( by deleting the entries from the SQL server directly). THIS IS NOT RECOMMENDED UNLESS YOU ARE AN EXPERT. PLAN FOR THE FARM BACKUP OR DISASTER RECOVERY BEFORE PERFORMING BELOW OPERATIONS.

  1. Run the below command:
    stsadm -o databaserepair -url -databasename [-deletecorruption]
  2. Get the XML out put and note down the corrupted site ID and all the corrupted List IDs
    To double check whether its a valid ID, go to the 'webs' table and check.
    Script:
    select * from webs where id = 'SITEIDABCD-ABCD.....'
    select * from aptb_lists where tp_id = 'LISTIDABCD-ABCD...'
  3. To Delete a orphaned LIST or DOC LIB entry in the content DB, follow the script:
    delete from aptb_lists where tp_id = 'Orphan list ID'
    delete from docs where tp_id = 'Orphan list ID'
    delete from Userdata where tp_id = 'Orphan list ID'
  4. To delete a site entry manually follow below scripts
    delete from webgroupmembership where webid= ‘LISTID'
    delete from webmembers where webid= ‘LISTID'
    delete from webs where id = 'LISTID'

Avoiding Orphans:

Some times, when you try to create a site collection from the central admin or stsadm, the site collection creation process takes several minutes. If you dont have the patience or skeptic that the creation wizard got hanged, then human tendency will try to close/back the window. But actually behind the screens, sharepoint was done with the site collection creatin part for some extent. At this time if the site collection creation process is paused or stopped by the admin, sharepoint leave the site as an orphan. Remind users that creating and deleting a site can be a sometimes several minute process. Regardless of how long it takes let the application itfinish what is doing. If it times out then try again but never click back, stop, or close the window when performing these types of administration tasks. Network Latency, Web front end performance and SQL backend performance can all attribute to a slow create or delete statement. Be patient .

More about the Orphans:
http://blogs.technet.com/corybu/archive/2007/05/31/sharepoint-orphans-explained.aspx

http://www.songhaysystem.com/kb/number/2076072084/subject/winos