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

Friday, November 30, 2012

SharePoint 2013 Enterprise Search Center deployment issues

A client had an issue recently trying to deploy the SharePoint 2013 Enterprise Search Center site as a standalone application (i.e. a central search for a large farm). In multiple attempts, they were unable to deploy - creating the application was fine, but the site would not create.

Reviewing the logs didn't tell too much - errors but nothing specific. In checking the system, it turns out they had enabled the Search Services but hadn't deployed a Search Application. I created the application OK however, deployment still failed - it took a reboot but the deployment finally worked!

Hope this saves you some time.

Monday, November 26, 2012

WSS Usage Application Proxy SharePoint 2013 Install


As was true with SharePoint 2010, SharePoint 2013 still has an issue with the WSS Usage Application. When a new farm has been installed and the Usage Application started, the Usage Application Proxy is not correctly enabled by default – this is a bug that must be corrected using PowerShell:

1) Login to the server running Central Administration, click Start > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell. In the PowerShell, type in:
Get-SPServiceApplicationProxy

2) This will return a list of the current service applications – you are looking for the WSS_UsageApplication for example:

DisplayName          TypeName             Id
-----------          --------             --
State Service App... State Service Proxy  e51696f1-3523-4e20-9b75-578485024b37
Managed Metadata ... Managed Metadata ... 830bafcf-f0d3-4254-91e4-8cfe11840e27
Search Service Ap... Search Service Ap... a988d821-8247-4294-ba11-961b22e51f8b
Application Disco... Application Disco... af617d69-7332-49f3-a61c-0eef3f7470cf
Excel Services Ap... Excel Services Ap... b6c5b951-7b4d-4837-83f3-c916c1ef6c7d
WSS_UsageApplication Usage and Health ... 83301455-c854-4596-af5c-0bc6ee963b6d

3) Copy the Id of the WSS_UsageApplication (Mark and copy), then enter the following commands:
$WUAP = Get-SPServiceApplicationProxy | where {$_.ID -eq "<copied Id>"}
$WUAP.Provision()

4) Close the PowerShell and double check the status in Central Administration > Application Management > Manage Service Applications - the Proxy should now be started.


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.