After an installation of SharePoint 2013 (upgrade or even if from bare metal), you may begin to see errors that state “Missing Server Site Dependencies” in which SharePoint says that there are [MissingWebPart] errors in the Administration Database.
One of the most common you will see is “[MissingWebPart] WebPart class [28c23aec-2537-68b3-43b6-845b13cea19f] is referenced [x] times in the database:
So you may wonder why Microsoft would do this to us? Turns out it is simply that certain features have not been installed yet (i.e. Services). So how do you determine what EXACTLY in the Web Part is causing the issue? Well you may have thought “I’ll just go to the content DB and look at the WebParts table” – aha – in 2013, you’ll find that table is gone (it is now called AllWebParts). Using a simple SQL Select you can get the title of the web part that’s missing.
Open up SQL Server Management Studio and open the database. Once there, expand the databases in the object explorer until you see the database names. Make a note of the SharePoint_AdminContent_<GUID> database (provided you have NOT renamed it). FYI – this applies to ANY content database; the Admin is to match the message above.
Now click New Query to create a new query window then enter the following SQL:
select DirName,LeafName from dbo.AllDocs where id in
(select tp_PageUrlID from dbo.AllWebParts where
Where ‘SharePoint_AdminContent_<GUID>‘ is your database name.
This query will return the results of the pages where the web parts were found – in the case of [28c23aec-2537-68b3-43b6-845b13cea19f], the query will show you that it’s the Search Web Parts found on the Search Administration pages:
Just in case you can’t see the images, the query above returned “SearchAdministration.aspx” and “SearchFarmDashBoard.aspx”
Now you may ask, why not just select the Web Part from the AllWebParts table – that’s because it won’t tell you what it is, just the ID. For example:
select * from dbo.AllWebParts where
Simply returns the ID’s of pages that the Web Part is on. It won’t tell you the name. Now in the above example, it is pretty easy to see what is missing – the Search Service has not been created so the components are not installed yet.
To find something a little more obscure, once you’ve identified one of the pages the Web Part is on, you can use the old ?contents=1 at the end of the page URL to see the web parts on it.
To further this – I investigated the issue on Search in specific. In reviewing of the components, the Search still uses SP2010 references and unfortunately, still uses “DWP” type web parts (5 in total).
All of the web parts required (and referenced in the code) are correct so this error should not be occurring. This is leading me to believe that the problem is in the database and likely can be overlooked. I’ve not traced the actual web part (since they are not on the pages in question) but I am leaning towards web parts installed by FAST – it is possible they have a FAST image installed when in fact, the pages do not include those parts.
After several folks checked out the issue and after multiple in-house tests, it appears that after re-analyzing the issue, it does appear that it does go away “most of the time” though be aware, it make take a couple of times. Other than that, it seems to be a non-issue.