Share via

SharePoint 2016: how to remove orphaned web parts for which tp_WebPartIDProperty equals NULL

  • Article

Problem

During an upgrade process from SharePoint 2013 to SharePoint 2016, as you're working through resolving various missing dependencies, you may experience the following:

.MissingWebPart TRUE FALSE WebPart class [d45f64e5-e285-b089-dae5-0e8a47b75972] (class [Microsoft.Office.Server.WebControls.ChartWebPart] from assembly [Microsoft.Office.Server.Chart, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]) is referenced [4] times in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [WSS_Content], but are not installed on the current farm. Please install any feature or solution which contains these web parts.

This non-upgrade blocking problem didn't appear in the Test-SPContentDatabase upgrade report you obtained when upgrading the content database from SharePoint 2010 to SharePoint 2013.  Restoring a full backup of the content database to a 2016 development farm, you open a new query window on the farm's SQL Server and then execute the following:

USE WSS_Content
SELECT SiteID, WebID, DirName, LeafName, tp_WebPartTypeId, tp_WebPartIDProperty
FROM AllDocs WITH (NOLOCK) inner join AllWebParts on AllDocs.Id = AllWebParts.tp_PageUrlID
WHERE AllWebParts.tp_WebPartTypeID = 'd45f64e5-e285-b089-dae5-0e8a47b75972'

which returns

SiteID WebID DirName LeafName tp_WebPartTypeID tp_WebPartIDProperty 
C1A41F57-9B36-4F02-A8DB-1CB6AE2555BF 19571030-4327-444F-9931-444FED7F1E1B web/Pages Page1.aspx D45F64E5-E285-B089-DAE5-0E8A47B75972
 NULL
C1A41F57-9B36-4F02-A8DB-1CB6AE2555BF 66C864FC-A29D-441A-9566-A4C08FA3F0E6 Pages Page2.aspx D45F64E5-E285-B089-DAE5-0E8A47B75972
 NULL
C1A41F57-9B36-4F02-A8DB-1CB6AE2555BF 66C864FC-A29D-441A-9566-A4C08FA3F0E6 Pages Page2.aspx D45F64E5-E285-B089-DAE5-0E8A47B75972
 NULL
C1A41F57-9B36-4F02-A8DB-1CB6AE2555BF 66C864FC-A29D-441A-9566-A4C08FA3F0E6 Pages Page2.aspx D45F64E5-E285-B089-DAE5-0E8A47B75972
 NULL

These results indicate that there is, in fact, a reference of the web part associated with the page, but that the reference is likely not associated with the current version of the page, meaning that the reference is associated with a previous version. You can verify this by simply going to the Version History dialog for the particular page and begin to click on the various version hyperlinks until you find the one that does have the chart web part on it.

Solution

To permanently remove the orphaned web part dependency from the upgrade report delete the page and then flush the deleted page file from the first and second stage recycle bins.

Notes

  • You can delete a specific version of the page file using the page file's Version History UI.  You can also delete it using PowerShell. For example, if you found the chart object on version 8.0 of the page file Page2.aspx, you would first execute the following:

    $web=get-spweb -identity "https://www.contoso.com/"
    $list=$web.lists["Pages"]
    $item=$list.items | Where {$_.File.Name -eq "Page2.aspx"}
    #do this to verify it shows up in the list
    $item.versions | ft -property VersionLabel,VersionID,CreatedBy -auto
    $version=$item.versions | Where {$_.VersionLabel -eq "8.0"}
    $version.delete()
    #then do this again to verify that it is gone
    $item.versions | ft -property VersionLabel,VersionID,CreatedBy -auto

    and then second, flush it from the first and second stage recycle bins.  However, from my experience, I found that even though I had removed the specific version of the page containing the web part (and also flushed this deleted version from the recycle bins), a reference to it persisted in the SQL script results.  After removing all of the versions, the web part still appeared in the SQL script results.  Disabling versioning for the document library had no effect.  The only solution I found for completely removing the orphaned web part from the upgrade report was to delete the page.

References