Error: The Search Display Templates Are Not Present on this Site Collection


I’m in the process of testing the new SharePoint Online Hybrid Search capabilities that have been released with the August 2015 Cumulative Update (KB3055009). I ran into an issue that I was able to resolve pretty quickly, but I wanted to share the solution I found.

Hybrid Search Information (This is in preview, do not deploy to production environments)

Issue

After running the Onboarding Script after all the errors had been dealt with, I attempted to create a new Result Source in my newly created Hybrid Search Service Application.

Here’s what I am doing

I am creating a result source to show only Remote (cloud) search results

  1. In Central Administrator of my on-premise farm I navigate to the newly created Hybrid Search Service Application
  2. Click Result Sources link in the left navigation
  3. Click New Result Source
  4. I enter the following settings
    • Result Source Form
  5. Click the Launch Query Builder button (see above)
  6. If it doesn’t appear automatically, click the Test Query button and you’ll see the following error below
    • Query Builder Error
    • Full Error Text: Build Your QueryThe Search display templates are not present on this site collection. To add them, you need to activate the “Search Server Web Parts and Templates” feature on the Site Collection Features page.Correlation ID: 13783c9d-e6d3-1051-1690-22b8fb473c46

Solution

Essentially, SharePoint is telling us that it doesn’t have all the Search features enabled in Central Administration. I have no idea why, since search and the query builder were working prior. The resolution for me was to run the below command.

  1. Open the SharePoint Management Console as Administrator
  2. Enter the following command
    1. Enable-SPFeature SearchWebParts -URL http://centraladministration:PortNumber
  3. Now try the Query Builder again and it should work

If you have questions or this doesn’t solve the issue for you please post a comment.

A Problem Occurred While Connecting to the Server


We’ve all gotten this error before.

ErrorOpening

This can mean any number of things. This article will describe a very specific situation that we discovered with one of our users.

Scenario

Library Settings Applicable to this Scenario

  • Require documents to be checked out before they can be edited? = YES

This setting can be found by navigating to the library > Library Settings > Versioning Settings

  •  Open in the client application

This setting can be set at either the site collection level or the library level

  • Site Collection = Site Actions > Site Settings > Site Collection Features
  • Library = Library Settings > Advanced Settings 

Issue

When a user attempts to open a document in the library noted above, they get the following messages.

New Open Behavior

Server Read-Only This document was opened from a server in read-only mode.

When the user clicks the Edit Document button they then receive this error

ErrorOpening

A problem occurred while contacting the server. If the problem continues, contact your administrator.

Cause

In this particular case, the cause was due to the site collection admin cutting and pasting the library into a manually created folder they had created in Explorer view.

Here are the steps they took to create the problem.

  • User navigated to the site in the web interface
  • Created 2 Document libraries named Library01 and Library02
  • Open the site in Explorer View
  • Right click and create new folder called Manually Created Folder (see image below)Before Library Move
  • Right clicked Library02 and selected Cut
  • Right clicked Manually Created Folder and selected Paste
  • Library02 now resides in the newly created Manually Created Folder

Reason

The reason this breaks the library is due to existing pointers in the content database that will still point to the original location.

Resolution

In order to repair this issue, you must reverse all changes performed

  • Open site in Explorer View
  • Navigate to the Manually Created Folder location
  • Right click Library02 and select Cut
  • Navigate up to the original location the library was created in
  • Right click and choose Paste
  • Right click the Manually Created Folder and choose Delete
  • The correct folder structure will look like the image below

Proper Structure

It’s easy to mistake a library for a folder within a library in Explorer View, and you may not notice any issues until you start using other features/settings within your library. The best advice is to just leave it alone unless you’re fully aware of what you’re doing. Luckily for this user, this was easily remedied and we haven’t seen any major issues because of it. Hopefully that will remain the case.

Troubleshooting Tip

Navigate to the Library Settings of the affected library. Now examine the URL of the library. Are there any directories in the URL that do not match up to a sub site in your site structure? If so, this is likely the folder that was created by the user

Error Opening SharePoint 2013 Site in SharePoint Designer 2013


I recently ran into a user who was getting the following error message every time they attempted to open their SharePoint 2013 site via the web interface in SharePoint Designer.

This action couldn’t be performed because Office doesn’t recognize the command it was given.

The pop-up message will look like the image below.

Untitled picture

The user had both SharePoint Designer 2010 and SharePoint Designer 2013 installed on their PC, which should not be an issue specifially as you can have both on the same computer without issues. You may find when you upgrade a particular SharePoint 2010 farm that your users will need to clear their SharePoint Designer cache in order for the new 2013 designer to work. The cache was not the issue here though.

Resolution

We found that the simple solution to the error was to re-install SharePoint Designer 2013 on the users workstation.

That simple action fixed the issue. The user had tried a repair of Designer which did no help, so a full uninstall then install was needed.

Hopefully this helps you if you run into this issue.

Gimme All Your Cache!


Those of us who have the wonderful job of managing a SharePoint farm know, installing patches can be a bit like playing roulette. This is especially true when installing Cumulative Updates, but not limited to.

Those of us who manage a SharePoint farm with multiple servers have definitely seen our fair share of messages like the one below.

Obviously, the first thing you need to verify, is that the noted patch is actually on all the servers. If it is, often we are then directed by sites, even mine, to manually run some combination of the PSCONFIG.exe command manually via powershell. This typically works because we’re forcing SharePoint to skip important version checks etc.

I highly recommend before you jump to any powershell that you follow the instructions on the site below.

SharePoint 2010 – Clearing the Configuration Cache

What this site is doing is clearing your configuration cache on each server before you attempt to run the SharePoint Configuration Wizard on any of your servers. The instructions specifically indicate they are for SharePoint 2010, but they work for SharePoint 2013 as well.

I’ve found I’ve even had issues running the PSCONFIG.exe manually and I still cannot get the config to finish. Clearing the cache is what works. You may need to reboot your servers, and you may even need to clear the cache twice, but soon, it will likely resolve the issue. So if you’re sitting stuck at 10% for forever, kill that PSCONFIG.exe task in the Task Manager and clear your cache. But don’t thank me, thank , the author of the above article.

KB2880994 Issue with Person Field – Fix


If your SharePoint environment is like ours and you wait a while to install hotfixes, Cumulative Updates, and Service Packs.

We recently discovered a problem with the following critical hotfix from Microsoft for SharePoint.

KB2880994

The issue we’ve run into and I believe there have been quite a few others also running into this is that in 2013 sites, when you attempt to Edit a list item that has a Person lookup field populated, upon editing, the field will go blank. If the user doesn’t realize it, they will save the list item and the person field is now blank. Data is lost.

The Assigned To field had a username in it, until clicking Edit.

The Assigned To field had a username in it, until clicking Edit.

I found the resolution was to Install the September Cumulative Update.

But, if you’re like us, and need more time to test the CU, you can simply install the below hotfix, which specifically addresses the issue.

KB2889884

There is no reboot required for this install and it will fix exactly this issue.

I hope this helps those of you having this issue. If you’re not aware of the problem, check the article, then check your farm.

SharePoint_Config_Log File Growing Too Large


If you manage both your SharePoint environment and your SQL environment, you may find that the SharePoint_Config_Log.ldf file keeps growing far too large. Here is a quick way to reduce the size of the file. There are other articles that explain how to do this for older versions of SQL server, but I found this one to work for me in my environment.

Environment

  • Windows Server 2012
  • SQL Server 2012 SP1
  • SharePoint 2013 Standard

Solution

  1. Run the SQL Server Management Studio 2012
  2. Select the SharePoint_Config database (you may have renamed yours)
  3. Open a new Query window
  4. Enter the following commands (Make sure you change the DB name if you don’t use the default name)
USE SharePoint_Config
GO
ALTER DATABASE SharePoint_Config SET RECOVERY 
SIMPLE
DBCC SHRINKFILE(N'SharePoint_Config_log', 1)
ALTER DATABASE SharePoint_Config SET RECOVERY 
FULL
GO

This will set the recovery mode of the configuration database to Simple which then will shrink the log file then it will reset the database back to FULL. I left mine as Simple as I have no intention of restoring my configuration database should there be an issue.

Sorry, we’re having trouble reaching the server


Recently we upgraded from SharePoint 2010 Foundation to SharePoint 2013 Standard/Enterprise. As with any upgrade there were some problems, but most were very minimal. This particular problem didn’t impact very many users, but was very frustrating.

Scenario

We had a list that we wanted users to submit a request to, this list we provided the user “Edit” permissions to, but no permissions to the rest of the site. When the user would attempt to complete the form they would get two errors. One during the form entry and one upon submission.

Error 1: Sorry, we’re having trouble reaching the server

Sorry_we're_having_trouble_reaching_the_server

This error is received in the “People Picker” fields of the list form. When attempting to enter a username or display name the user continually receives this message.

Error 2: The server was unable to save the form at this time, Please try again

The_server_was_unable_to_save_the_form_at_this_time

This error is received after completing the form and clicking the Save button

I started out as anyone does looking to Google (I even tried Bing) but all the articles I found that had a similar error message and scenario just didn’t solve the issue. Here some of the things I tried without success.

  • Reload the .NET HTTP Activation
  • Checked and re-checked Alternate Access Mappings.
  • I even tried adding permissions so the users could at least get the People Picker field to successfully run a user query, but I stil couldn’t save.
  • Backup/Restore of Site Collection to same location and different location

Solution

After all of that, I found the simplest of answers that just annoyed the crap out of me. I found that new site collections weren’t displaying the same issues so I decided I needed to start comparing the two. I started in the Site Collection Features menu and sure enough, there was my answer.

On the problem site collection I had the SharePoint Server Publishing Infrastructure feature Activated, which isn’t the cause of the problem directly, but it does by default enable the Limited-access user permission lockdown mode feature. Below is the description of the feature.

Limited-access_user_permission_lockdown_mode

 

There isn’t a lot of documentation on this feature, but when you Deactivate the feature, the issue goes away. It makes sense though that the issue would occur based on the description. It seems this is a security feature for public facing publishing sites so you aren’t accidentally sharing more data with anonymous users than expected, the problem is other users who not using anonymous access but do not have permissions to the top level site will also not be able to edit. Viewing is not affected.

This took me way too much time to solve, and I wish Microsoft didn’t make the default behavior to enable this feature, but such is the case. I hope this helps someone else out there. Good luck.