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 is 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
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.
NOTE: If you want to find the solution, skip to the end of this post - for those of you that have this issue with other web parts, read on:
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.
I am still investigating but did stumble upon one issue that may be partially the cause (and would be using the Autoinstaller script - something I do NOT recommend). Be aware that while handy, the AutoInstaller script should NOT be used in a production environment - it only leads to scripting and version problems since each environment requires a unique one. In addition, it is only good for the first server.
The issue appears to be if the Search Service is created with the wrong account (in one of my tests, the Farm account was used and the issue appeared). Changing the account after the fact does not fix the issue.
One other attempt was to remove the search service and create a new one - this is proving very difficult as the service is only partially removed.
I will post an update when I determine the exact cause.
It is not apparent what is causing the problem - I have removed the Search Service (unsuccessfully) and was unable to re-provision. I also attempted a repair with no change. I will rebuilding that server to see if the problem returns.
I am suspecting that this might be some kind of a bug or misreporting in the health analyzer. The only inconsistencies to be found are in the Feature.xml references V14 Resources, not V15 (2013). This is located as the Search Admin feature (c:\program files\common files\microsoft shared\web server extensions\15\template\features\SearchAdminWebParts):
<?xml version="1.0" encoding="utf-8" ?>
<!-- Copyright (c) Microsoft Corporation. All rights reserved. -->
ReceiverAssembly="Microsoft.Office.Server.Search, Version=18.104.22.168, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
This "may be OK" but not sure why they would reference the V15 DLL but resources from 14 - the SearchAndProcess feature also appears this way.
More to come...
Mixed results - this does appear on most installs (well 4 of 6 did). Two of the four, the issue went away after doing a 'Reanalyze'. The other two still show the message (still investigating) - of those, I corrected by uninstalling SharePoint.
Regardless, it does not seem to adversely affect the farm operation in search.
I'll post another update if anything else comes up.
After review of all comments and testing, it appears that:
1) The problem appears to go away "most of the time" when simply re-analyzing
2) Browsing to the pages may help
In both cases, it make take a couple of times.