After posting articles on diagnosing MissingFeature
and MissingSetupFile
errors in the SharePoint 2010 Health Analyzer and Test-SPContentDatabase
operation, I have become slightly obsessed with doing the same for other errors,
too. I have also had my fair share of them on migration projects recently, so I
can’t be the only one experiencing them at the moment.
In this article I am going to focus on MissingWebPart and MissingAssembly errors. As stated in previous articles, there is no silver bullet to solving these errors in all cases, but the scripts offered here will allow you troubleshoot the errors further to find exactly where they are happening in the content database. Once you know this, you have a fighting chance of being able to solve the problem.
MissingWebPart Error
In this example, I have received the following error whilst running a Test-SPContentDatabase operation after a content database migration from SharePoint 2007 to 2010. It also appears in the SharePoint Health Analyzer under the “Configuration” category with the title “Missing server side dependencies”:
Category : MissingWebPart
Error : True
UpgradeBlocking : False
Message : WebPart class [4575ceaf-0d5e-4174-a3a1-1a623faa919a] is referenced [2] times in the database [SP2010_Content], but is not installed on the current farm. Please install any feature/solution which contains this web part.
Remedy : One or more web parts are referenced in the database [SP2010_Content], but are not installed on the current farm. Please install any feature or solution which contains these web parts.
As you can see, the error gives you a “WebPart class” GUID, the name of the content database, and how many times it is referenced in the database, but little else. What we need to find out here is either the name of the web part or on which pages it is referenced in the database.
For this I am going to reuse the Run-SQLQuery PowerShell script that I introduced in my article on MissingSetupFile errors:
Id : 6ab5e70b-60d8-4ddf-93cb-6a93fbc410be
SiteId : 337c5721-5050-46ce-b112-083ac52f7f26
DirName : News/Pages
LeafName : ArticleList.aspx
WebId : dcc93f3e-437a-4fae-acea-bb15d5c4ea7d
ListId : 7e13fe6c-3670-4d46-9601-832e3eb6a1e4
tp_ZoneID : Body
tp_DisplayName :
Id : b3fcfcd2-2f02-4fe9-93e4-9c9b5ecddf5b
SiteId : 337c5721-5050-46ce-b112-083ac52f7f26
DirName : Pages
LeafName : Welcome.aspx
WebId : 2ae0de59-a008-4244-aa66-d8f76c79f1ad
ListId : d8f083f0-16b9-43d0-9aaf-4e9fffecd6cc
tp_ZoneID : RightColumnZone
tp_DisplayName :
This tells us that the web part has been found on two pages (the references mentioned in the MissingWebPart error). SiteId tells us the site collection and WebId the site where the pages are located. We also have a DirName showing the relative path and the page name itself against the LeafName property. If you’re lucky, you might get the display name of the web part against the tp_DisplayName property, but if not, you should at least be able to tell which zone the web part has been added to by looking at the tp_ZoneID property.
Easily the best way of resolving these issues is to do as the error suggests and install the missing feature or solution containing the web part, but if this is not possible or feasible to do in your scenario, we can discover the site collection URL from the GUIDs using PowerShell and then remove the offending web parts from the pages specified. To find the site collection URL using the information output from the query, type the following command:
Also note that if you do decide to delete a workflow or a file from the site, remember to remove the file from the site Recycle Bin and Site Collection Recycle Bin to ensure the file is removed from the content database. If not, the error may not disappear from the Health Analyzer.
In this article I am going to focus on MissingWebPart and MissingAssembly errors. As stated in previous articles, there is no silver bullet to solving these errors in all cases, but the scripts offered here will allow you troubleshoot the errors further to find exactly where they are happening in the content database. Once you know this, you have a fighting chance of being able to solve the problem.
MissingWebPart Error
In this example, I have received the following error whilst running a Test-SPContentDatabase operation after a content database migration from SharePoint 2007 to 2010. It also appears in the SharePoint Health Analyzer under the “Configuration” category with the title “Missing server side dependencies”:
Category : MissingWebPart
Error : True
UpgradeBlocking : False
Message : WebPart class [4575ceaf-0d5e-4174-a3a1-1a623faa919a] is referenced [2] times in the database [SP2010_Content], but is not installed on the current farm. Please install any feature/solution which contains this web part.
Remedy : One or more web parts are referenced in the database [SP2010_Content], but are not installed on the current farm. Please install any feature or solution which contains these web parts.
As you can see, the error gives you a “WebPart class” GUID, the name of the content database, and how many times it is referenced in the database, but little else. What we need to find out here is either the name of the web part or on which pages it is referenced in the database.
For this I am going to reuse the Run-SQLQuery PowerShell script that I introduced in my article on MissingSetupFile errors:
function Run-SQLQuery ($SqlServer, $SqlDatabase, $SqlQuery)Once you have loaded the function in a PowerShell console, you can run it by using the Run-SQLQuery command with the options relevant to your deployment. For [MissingWebPart] errors, you need to run a SQL SELECT query on the “AllDocs” table in the content database exhibiting the problem, joining to the “AllWebParts” table in order to find details about the missing web part. For example, you would type the following command to find details of the web part with the class ID “4575ceaf-0d5e-4174-a3a1-1a623faa919a”, as reported in the error above:
{
$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Server =" + $SqlServer + "; Database =" + $SqlDatabase + "; Integrated Security = True"
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $SqlQuery
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$SqlConnection.Close()
$DataSet.Tables[0]
}
Run-SQLQuery -SqlServer "SQLSERVER" -SqlDatabase "SP2010_Content" -SqlQuery "SELECT * from AllDocs inner join AllWebParts on AllDocs.Id = AllWebParts.tp_PageUrlID where AllWebParts.tp_WebPartTypeID = '4575ceaf-0d5e-4174-a3a1-1a623faa919a'" | select Id, SiteId, DirName, LeafName, WebId, ListId, tp_ZoneID, tp_DisplayName | Format-ListYes, it is a pretty long command, but it will produce a very useful output, as shown in this example:
Id : 6ab5e70b-60d8-4ddf-93cb-6a93fbc410be
SiteId : 337c5721-5050-46ce-b112-083ac52f7f26
DirName : News/Pages
LeafName : ArticleList.aspx
WebId : dcc93f3e-437a-4fae-acea-bb15d5c4ea7d
ListId : 7e13fe6c-3670-4d46-9601-832e3eb6a1e4
tp_ZoneID : Body
tp_DisplayName :
Id : b3fcfcd2-2f02-4fe9-93e4-9c9b5ecddf5b
SiteId : 337c5721-5050-46ce-b112-083ac52f7f26
DirName : Pages
LeafName : Welcome.aspx
WebId : 2ae0de59-a008-4244-aa66-d8f76c79f1ad
ListId : d8f083f0-16b9-43d0-9aaf-4e9fffecd6cc
tp_ZoneID : RightColumnZone
tp_DisplayName :
This tells us that the web part has been found on two pages (the references mentioned in the MissingWebPart error). SiteId tells us the site collection and WebId the site where the pages are located. We also have a DirName showing the relative path and the page name itself against the LeafName property. If you’re lucky, you might get the display name of the web part against the tp_DisplayName property, but if not, you should at least be able to tell which zone the web part has been added to by looking at the tp_ZoneID property.
Easily the best way of resolving these issues is to do as the error suggests and install the missing feature or solution containing the web part, but if this is not possible or feasible to do in your scenario, we can discover the site collection URL from the GUIDs using PowerShell and then remove the offending web parts from the pages specified. To find the site collection URL using the information output from the query, type the following command:
$site = Get-SPSite -Limit all | where {$_.Id -eq "337c5721-5050-46ce-b112-083ac52f7f26"}One you have the site collection URL, you can use the relative path specified by the DirName property to find the location of the file. To remove the web part from the page, type the page URL in the browser and add ?contents=1 to the end of it. For example, to open the web part maintenance page for the ArticleList.aspx page specified in the output, type the following URL in the browser:
$site.Url
http://portal/news/pages/articlelist.aspx?contents=1Note: If you remove an ErrorWebPart from a publishing page with versioning switched on, you may have to delete all earlier versions of the page before the error disappears from the SharePoint Health Analyzer or Test-SPContentDatabase report. This is because the web part will still be referenced from these versions, even though you removed it from the currently published page.
Also note that if you do decide to delete a workflow or a file from the site, remember to remove the file from the site Recycle Bin and Site Collection Recycle Bin to ensure the file is removed from the content database. If not, the error may not disappear from the Health Analyzer.
