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.

Advertisements

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.

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

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.

SharePoint 2013 Error Writing to RBS Enabled Database


I recently configured a SharePoint 2013 Standard environment for a customer who required RBS for a video streaming service they wanted to build in SharePoint and I came across the following errors.

This is an array of errors I got depending on the site template (2010 vs. 2013) or what service I tried to write with, such as using Windows Explorer or using the Upload Document web interface.

This slideshow requires JavaScript.

Architecture

The architecture of this SharePoint environment was quite simple as you can see below.

  • SharePoint 2013 Standard
  • SQL Server 2012 Standard
  • RBS (FileStream)

All of this lives on the same physical server.

Symptoms

After having configured the SharePoint 2013 content database to use RBS as prescribed in the very useful instructions HERE, the end user gets the above error messages. Most often, the message states something similar to the below message.

Sorry, something went wrong

The URL ‘Shared Documents/filename.docx’ is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not within the current Web.

You will find later, that this error is not very helpful.

No new documents can be uploaded or created, and existing documents cannot be edited or removed.

Troubleshooting Attempts

I spent and inordinate amount of time troubleshooting this issue. Google searches of the error turned up little useful information. The most common articles I found typically were related to folks that could write small files under 1MB but anything larger wouldn’t write. That wasn’t helpful as I couldn’t write anything.

Checking the BLOB file location and it appeared that I had RBS setup right as the folder was created.

Resolution

It turns out the issue was a permissions issue (as I had expected). It was a SQL permissions issue with the Web Applications service account.

I found that when I added the service account to the db_owner role on the content database, all of a sudden I could write to the site with new files, modify existing files and even delete files. Even the RBS portion was working just fine writing to the BLOB store.

Long story short, here are the instructions to manually add your service account for the web application to the db_owner role on the content database.

  1. Open SQL Server Management Studio
  2. Expand the Database folder
  3. Expand the specific content database you’ve configured for RBS
  4. Expand the Security folder
  5. Expand the Roles folder
  6. Double click db_owner (see below)
  7. SQL Database DBO
  8. In the Role Members section click the Add button (see below)
  9. SQL DBO Add
  10. Select the Web Application Service Account and click OK
  11. Click OK until you have returned to the screen from step 6 above
  12. You should now be able to write to your RBS enabled Content Database

I searched the web for quite some time and found no articles that was experiencing this issue so perhaps it was just a fluke. At first, I thought it was because I pre-created my content databases, but I did try letting SharePoint create the content database through the Add Content Database menu in Central Administration but I had the same issue.

I hope if you are experiencing this issue you find this article and it helps quicker than it took me to find the solution.

SharePoint 2013 Search Stopped Working


SP_2013_Search_Error

Search has encountered a problem that prevents results from being returned. If the issue persists, please contact your administrator.

I’ve been working on a SharePoint 2013 Standard farm for a customer, trying to get RBS configured, and low and behold, I discovered that Search had stopped working and was providing the above error message. No search would work, from any search center from any Web Application throughout the farm.

It didn’t take too long to figure out the issue, but it certainly was cause for alarm since I’ve been having issues with RBS.

What was the problem?

Turns out, the issue was due to URLs being configured in the Content Sources that either didn’t exist, or did not have a proper DNS entry that pointed the server to the correct location.

Steps to Resolve

  1. Navigate to Central Administrator
  2. Click Application Management
  3. Click Manage service applications
  4. Click Search Service Application
  5. Under Crawling section click Content Sources
  6. Click Local SharePoint Sites
  7. In the Start Addresses section (see below) remove all URL’s that do not exist
  8. Click OK
  9. Try search again and it should now work

Why are these URL’s a problem?

My search server was locking up whenever a crawl would run. This meant that a full crawl or even an incremental crawl never finished. Obviously the issue was due to the site not existing or not being available for the crawler to index the content.

I hope this helps, should you run into this error. Mind you, this error is not indicative to only this issue. I am not saying that just because you get this error that you should assume the only solution is a bad URL in the Content Source. I’m sure if I search my Event Viewer logs I’ll find some events in there indicating those URL’s I removed were not accessible in some way.