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)

• Getting Comfortable with the new hybrid Cloud Search Service in SharePoint 2013
• Cloud Hybrid Search Service Application
• Download Hybrid Search Onboarding Scripts
• TechNet Support Forum

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

Advertisement

A Problem Occurred While Connecting to the Server

We’ve all gotten this error before.

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.

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

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)

• 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

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

You Know You’re A Nerd When…

You know you’re a huge nerd when… You send jokes to your co-workers complaining about leadership via Lync using fake PowerShell commands.

Wow! It’s getting really nerdy up in here today. 🙂

Joke of the day today.

Set-SPExpert -Identity “Leadership” -Force -ErrorAction SilentlyContinue

Wow! That’s so bad.

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.

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 James Waymire, the author of the above article.

Weight Loss Challenge – Day 9

It’s the end of day 9. Bet you thought I was going to miss today didn’t you? Today was a pretty bad day. Not because of diet or exercise. Work was overbearing. It started with an Implementation that didn’t get finished until 2:00am because my Internet went down at home at the most inopportune time.

So, I got up at 6:00am, to come to find our Office Web Apps service was not working. Long story short. By 2:00pm, I had that issue resolved, and low-and-behold, I hadn’t eaten lunch, and my breakfast was tiny.

Technically then, my diet was going great. I didn’t ever get to eat lunch today. I had a large supper, which filled me to the point of not being able to put anymore in me, and I was still 200 calories short of my daily allotted allowance of calories.

Bad work day, great challenge day. Time to look at the bright side. I see today as a win.

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.

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

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

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.

 

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.

Sign In As Different User, Where’d You Go My Friend?

Those of us used to the SharePoint 2010 interface should be familiar with the Sign in as Different User option. It was a great feature that helped immensely with troubleshooting and developing in SharePoint.

Low and behold, in SharePoint 2013, this feature is gone. Of course, if you’ve installed 2013, you already knew this. This is old (OOOOOLLLLLDDDDD) news. What might not be old news, is there is a simple way to force SharePoint to allow you to still use the feature. Here it is, in all it’s glory.

On any URL in your SharePoint farm, add the following to the end of the URL.

/_layouts/closeConnection.aspx?loginasanotheruser=true

So your URL will look like this: http://<URL>/_layouts/closeConnection.aspx?loginasanotheruser=true

You’ll then be presented the standard windows authentication box. Go ahead and login as your different user and you’re ready to go.

**WARNING** It seems the feature must have been removed due to caching issues. In testing on my own, I found Logging out using the SharePoint Interface or even closing the Browser tab does not clear the “different” user credentials, thus it is possible for the user who owns the Windows session to still be able to access a SharePoint site as the new account. Even after they have logged back in as themselves. The only remedy for this seems to be to close the browser itself. Even clearing the cache doesn’t always do it.

Be careful using this option. A better way might be to simply run Internet Explorer as yourself, then close when your’e done. Using the above method, though is a great way to test if there are issues with the users profile or settings in the profile such as Internet Explorer settings.

I hope this helps someone.