SharePoint Experts, Information Architects, Expert Witness

We provide consulting in a broad array of business and technology from architecture to design to deployment of global systems with a focus on surfacing data in the enterprise. Specialists in Microsoft, we are a premier provider of SharePoint Expertise (including 2016 and Office 365). We also provide Expert Witness/Legal Expert in eDiscovery, source discovery, patent infringement, piracy and more! We also have established SICG DLDS s.a. - our counterpart in Costa Rica that specializes in water systems (http://www.crwatersolutions.com) - Contact me direct: david_sterling@sterling-consulting.com or call 704-873-8846 x704.

Search This Blog

Sunday, November 25, 2012

SharePoint 2013 Missing Server Side Dependencies

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 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:


use [SharePoint_AdminContent_<GUID>]
select DirName,LeafName from dbo.AllDocs where id in
 (select tp_PageUrlID from dbo.AllWebParts where
    (tp_WebPartTypeID='28c23aec-2537-68b3-43b6-845b13cea19f')
 )
go

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:


USE [SharePoint_AdminContent_<GUID>]
select * from dbo.AllWebParts where
tp_WebPartTypeID='28c23aec-2537-68b3-43b6-845b13cea19f'


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:
-----
UPDATE: 

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.

UPDATE 2:

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. -->
<Feature  Id="C65861FA-B025-4634-AB26-22A23E49808F"
          Title="$Resources:SearchAdminWebParts_Feature_Title;"
          Description="$Resources:SearchAdminWebParts_Feature_Description;"
          DefaultResourceFile="Microsoft.Office.Server.Search"
          Version="14.0.0.0"
          Scope="Web"
          Hidden="TRUE"
          AutoActivateInCentralAdmin="TRUE"
          xmlns="http://schemas.microsoft.com/sharepoint/" 
          ReceiverAssembly="Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
          ReceiverClass="Microsoft.Office.Server.Search.Administration.SearchFarmAdminUIFeatureReceiver">
    <ElementManifests>
        <ElementManifest Location="webPartDWPFiles.xml"/>
        <ElementManifest Location="farmdashboardprovision.xml"/>
        <ElementManifest Location="searchappdashboardprovision.xml"/>
        <ElementManifest Location="searchadminlinks.xml"/>
    </ElementManifests>
</Feature>


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...

UPDATE 3:

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.

FINAL UPDATE:

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.



10 comments:

Anonymous said...

Thanks for explaining how to figure out what's missing.. but the most important question would be.. how to install the pieces that are missing? :) I have Search Center installed, but am still getting this notification. I have used SPAutoInstaller from CodePlex, maybe the problem lies in that.

Levent Curtasan said...

I has the same issue with a fresh install of SharePoint 2013 (no AutoSPInstaller). I ran the SQL query and it returned the /searchfarmdashboard.aspx page, but after accessing it and hitting Reanalyze Now the problem dissapeard. Hope it helps.

von Borries, Danny said...

I had the same issue.
The SQL query returned "SearchAdministration.aspx" and "SearchFarmDashBoard.aspx".
Opened both sites in edit-mode closed it and reanalyzed the rule.
After that the problem has disappeared.

George Begbie said...

So it seems that accessing the Farm Search Administration page, followed by re-running the analysier fixes the issue. I did do this a few times, too.

Nils said...

I had the same issue. Have a look at http://consulting.risualblogs.com/blog/2013/03/04/reporting-server-addin-for-sql-2012/ and install http://www.microsoft.com/en-us/download/details.aspx?id=35583 :-)

Anonymous said...

Great post.
To be honest I'm not surprised about this issue, 2010 had something familiar.
Anyway, after I edited (without making changes of course) both Search Administration & Farm Search Administration pages, the error was gone.

Anonymous said...

What do you do when you get this; I am not given a GUID and reanalyze isnt working.

[MissingSetupFile] File [Features\SubWebs_SubWebsFeature\ShowSubWebs\SubWebs.webpart] is referenced [1] times in the database [EnRoute_Content], but is not installed on the current farm.

David M. Sterling said...

That is a third part web part from CodePlex (https://sharepoint247.codeplex.com/).

Installing the feature will remove the error but it sounds like you want to get rid of it. You can easily find it using the PS Script here:

http://blog.riccardocelesti.it/list-all-webparts-in-page-using-windows-powershell/

Apun sehgal said...

I have a specific scenario, in which we have removed a webpart from all pages in the farm. For which we had done following:
Deactivate feature
remove webpart from pages
retract and remove solution.
Now the issue is that we get in reports "Missing server side dependencies". We looked into it and the webpart is removed from pages, but in case of Publishing pages the webpart reference exist in old versions.

How to resolve this issue.

David M. Sterling said...

Sorry for the delay - if you are getting Missing Server Side Dependencies, the part is "SOMEWHERE"; what it means is that the part itself may have been closed and not deleted on some page. Technically, it won't impact your farm but will impact if you try to upgrade later.

One solution is here:

http://stackoverflow.com/questions/1498409/sharepoint-find-where-webpart-is-in-use

This is probably better (from previous note):

http://blog.riccardocelesti.it/list-all-webparts-in-page-using-windows-powershell/