SharePoint 2010 - Removing Orphaned WebParts

3 minute read

While troubleshooting a completely different issue in one of our SharePoint 2010 test farms, I noticed an error reported in the "Health Report" in the central admin. The error "Missing server side dependencies" came up with an explanation saying "WebPart class [GUID] is referenced [x] times in the database [ContentDB], but is not installed on the current farm."


In my case this was a web part we used back before the site had been upgraded to sharepoint 2010. Amazingly, the web part was still working even though SharePoint 2010 was flagging it as an orphan. In this case that's fine, I wanted to remove the web part from all pages anyway.

...so how in gods name do I find what pages the WebPart is on?

Thanks to Phil's blog post "Diagnose MissingWebPart and MissingAssembly issues from the SharePoint Health Analyzer using PowerShell" I was able to figure this out. Here is my rehash of Phil's info, connecting to SQL server directly rather than using powershell.

Query Against the WebPart GUID
Snag the WebPart GUID from the error message, then use SQL server management studio to connect to your SharePoint 2010 content database.  Run the following query, replacing the GUID with your WebPart GUID.

SELECT Id, SiteId, DirName, LeafName, WebId, ListId, tp_ZoneID, tp_DisplayName
from AllDocs
      inner joinAllWebParts on AllDocs.Id = AllWebParts.tp_PageUrlID
whereAllWebParts.tp_WebPartTypeID = '8a860dca-4061-d270-a67b-f6bde7fc3e0a';


The DirName gives you the path to the page you want ("/MySubSite/Pages") and the LeafName gives you the name of the page ("default.aspx"). 

Map The SiteId GUID To URL
If you have more than one site collection in your farm, the SiteID tells you what collection you are dealing with. You'll want to map the SiteID to a website URL, so bust out the sharepoint powershell prompt on your central admin server and run the following command:

PS c:\> Get-SPSite

it should output a list that looks something like this:

Url                                                         ID

---                                                         --
http://MySite1                                         707f838a-56ab-475b-9a52-fdf05a8f3e7a
http://MySite2                                         11c04ca8-ad58-4147-8344-8132e5788090


The ID in the above table maps back to the SiteId from the SQL query - and there you have your URL to SiteId mapping! Hooray!

Now you can put it all together to get the full URL of the pages you need to fix.

Removing Bad WebParts
Sadly, this can be tricky part. When you start deleting the bad WebPart, keep these things in mind:

  • DELETE the web part from the page. Do not use the "Remove" option, which only hides the web part instance rather than delete it.
  • You can quickly view all WebParts assigned to a page and delete them by appending "contents=1" to the url. Ex: "http://mysite/Pages/default.aspx?contents=1" (Another great tip from Phil, thanks!)

  • If you have the publishing feature enabled, you could have instances of the web part linked to old versions of your page.  Be sure to delete the version history of the page if necessary ... and if you do that, you will need to also empty the SharePoint recycle bin ... and -then- empty the "Second Stage" SharePoint recycle bin if you have it enabled in the central admin, which only the Farm Admin can do from the site collection root settings page.  To get to the Second Stage recycle bin, you can login to the front end site as a farm admin account and hit the url "/_layouts/AdminRecycleBin.aspx". Then pick the option "Deleted from end user Recycle Bin".


Verify All Instances Are Gone
Once you've deleted the web part from all pages, do a sanity check - run the SQL query again to confirm no records are returned.  You can also run the "Health Check" again by hand to confirm SharePoint agrees that the web part is gone.  Fire up the SharePoint PowerShell command prompt and run the command "Test-SPContentDatabase" shown below, but of course swap out the content database and web application names for your own.

PS c:\> Test-SPContentDatabase -name MYSP2010-Content -WebApplication http://MyApp