Help to avoid and partially clean up missing server side dependencies

Orphaned items within sites can cause all sorts of issues:  Missing Server side dependencies, Sites not replicating correctly amongst farm servers, trouble with cumulative updates, odd web part behavior, and who knows what else.

It’s been my experience that server side dependencies result from numerous things, such as poorly written code that is not tested correctly in a development environment.  Code that deploys fine, but does not retract cleanly after successful deactivation of it’s features. Or features that are not deactivated before the solutions, that deployed said feature(s), are retracted and\or removed.

One way to avoid dependencies and orphaned SharePoint features

Before retracting a solution, make sure to deactivate the SharePoint feature or features that the solution provided.  You can do this by knowing which of the thousands of sites you support have the feature activated, or you could run a script written by Gary Lapointe, founding partner of Aptillon that deactivates or activates the feature:

One way to clean out some, not all, of your server side dependencies

Orphaned sites, lists, libraries, documents, and references often result when features are unable to be deleted due to solutions that they were dependent on are no longer present in the farm.  This occurs when solutions are retracted and removed without features first being deactivated, followed by deletion of the site, list, library, document, or item that referenced a feature that was referencing a solution that was erroneously retracted.    In cases of site deletion, this is true despite SharePoint reporting back that “Your web was deleted”.  In actuality, it may or may not be completely deleted.

No PowerShell for this, yet

Use the DatabaseRepair switch of the somewhat deprecated stsadm command to dig in and even remove some server side dependencies.    “Isnt the stsadm deprecated to  the Management Shell\PSSnapin for SharePoint”  and the answer is yes, in most cases it is.  But in this case and unlike many other stsadm switches, -databaserepair has not been replaced by powershell.

Here is the official list of all the stsadm switches, that powershell is about to replace, at the time of this post: – stsadm to powershell chart

Reason for “Partially clean up” in the subject line

“The databaserepair operation can detect and repair database corruption for only the following types of orphaned items in a content database:

  • A Windows SharePoint Services Web site that does not have a parent Windows SharePoint Services Web site
  • A subweb that does not have a parent Windows SharePoint Services Web site
  • A list that does not have a parent Windows SharePoint Services Web site
  • A document that does not have a parent document library
  • A list item that does not have a parent list
  • A Web page that does not have a parent Windows SharePoint Services Web site
  • Missing security scopes on Webs, lists and items” – TechNet –

It’s best to make a backup of your site, backup-spsite, before proceeding, and even better to perform this in a development or testing environment.

Here are the steps detect the issues that are causing the corruption:

  1. Backup the site using backup-spsite
  2. Know the name of the content database of the site, you could get this using the GUI or powershell.  If (Get-SPwebApplication <URL>).contentdatabases returns more than one content databases, one way to find the content db hold your site is to run (get-spcontentdatabase <Name of Database>).sites on each database.  Or you could probably find a script for that somewhere
  3. stsadm -o databaserepair -url -database wss_content_8083

Here are the steps to remove the corruption\repair the issues:

  1. Steps from above
  2. stsadm -o databaserepair -url -database wss_content_8083 -deletecorruption


Examples from Technet

Detect an orphan site

To detect orphaned items, use the following syntax:

Delete an orphan site

To delete orphaned items, use the following syntax: