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

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.

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.

Issue: The search request was unable to connect to the Search Service

I installed Service Pack 2 on our SharePoint 2010 Foundation production farm last night and everything went as expected. The test scripts all passed which was awesome. I then proceeded to fix a few minor issues. One was an orphaned record alert in the Health Analyzer which we get from time to time and using the auto fix option within the alert has always fixed that issue which it did. I then proceeded to increase the page file size which I believe is the trigger that caused us to get the below error when I ran our test scripts and search had stopped working.

The search request was unable to connect to the Search Service.

Anytime search stops working in Foundation it’s a little freaky and I usually run to our DBA’s to make sure our DB permissions haven’t changed, but I decided to hold off and just got a hunch to do the following.

1. Go to Central Administration > Upgrade and Migration > Review database status
2. Ensure no databases require upgrade (Status should indicate “No action required”)
3. Click on a content database
4. Verify the correct search server is selected in the drop down
5. Click Ok
6. Repeat for all content databases

This resolved my search issue. It was as though the system lost it’s setting to identify which search server to use for the content database.

Disaster averted. Hopefully if anyone else experiences this issue this will help.

ISSUE: KB2844286 Security Update on SharePoint 2010

Came in today to find the following error message showing up on seemingly random web parts and lists throughout our SharePoint 2010 Foundation farm. ULS Logs on the servers weren’t very helpful.

[This issue has been RESOLVED see updates below]

For the sake of search indexing, here is the text version of the error we are getting.

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

We quickly tracked it down to a Security Update that was applied to our web front end servers last night. Check the OS below to find the KB update associated with your server.

Windows XP and Windows Server 2003

• KB2844285

Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1

• KB2844286

Windows Vista Service Pack 2 and Windows Server 2008 Service Pack 2

• KB2844287

This is in regard to the following Microsoft Security Bulletin for July 2013

Microsoft Security Bulletin MS13-052

As a temporary workaround, we found uninstalling the update (KB2844286) from your servers (all WFE’s and App servers) then performing an IISReset on the servers will resolve the issue. Several others have experienced this issue as noted in just one of many forums such as the one below

http://social.technet.microsoft.com/Forums/sharepoint/en-US/cc9a557b-93cd-40d5-965c-e0a2f107624d/unable-to-display-this-web-part-error-message-after-patch-kb2844286

If I find there is a solution better than uninstalling I will update this post to reflect that. As of right now, uninstalling this update is the best option.

[Update 7/16/2013 3:40pm]

It appears the error typically appears when a list or web part view has had the XSLT customized. At least in our Farm, that has been the common behavior.

[Update 7/17/2013 10:03am]

Not much of an update, but I’m awaiting contact from our Microsoft TAM to see about this issue. If we don’t hear from them soon, then we’ll be opening a ticket with Microsoft. Luckily we were able to work around the issue by uninstalling.

[Update 7/17/2013 12:50pm]

I just received confirmation from our TAM that Microsoft is aware of 2 issues regarding the patch noted in this article above. One of which appears to be the SharePoint issue we’re having.

[Update 7/17/2013 2:43pm]

Just spoke with our Microsoft Sr. Support Escalation Engineer assigned to our premier support ticket and here is their response (summarized).

“Our product group is currently working on the updated patch. We have no ETA for the new release at the moment.”

Looks like we wait then for a resolution.

[Update 7/17/2013 2:59pm]

One more confirmation from Microsoft Support and a link to the forum MS is using to track the issue publicly. No public information just yet beyond that, however.

“Both the SharePoint and .NET product groups are aware of the issue and they are in the process of fixing the patch.”

Follow the issue at this TechNet Forum

[Update 7/18/2013 9:24am]

So far I have heard of no updated patch being released yet by Microsoft. There were two MS Security Bulletin updates but it doesn’t appear they were related to this issue as they were for Bulletin MS12-006 and MS12-052.

[Update 7/21/2013 12:36pm]

Still no updated patch. Received an e-mail from our MS Support representative and they indicated they too have no ETA on any updates to the security patch. I guess I’d rather they take their time then rush an update out all to break something else. It would be a good idea if Microsoft were to either add a note to the update download page indicating the issue, or just pull the update altogether.

[Update 7/24/2013 8:28am]

I just got a message from our Microsoft Support representative and she informed me there is no update as of yet on a new download for the patch. No surprise there.

[Update 7/25/2013 7:50am]

As you can see from the comments that have arrived thus far, it appears Microsoft has provided a fix to the KB2844286 issue. We are in the process of testing it out in our DEV environment now. Let’s hope it fixes it and doesn’t cause more issues.

[Update 7/25/2013 8:22am]

I am at this point, comfortable with counting this issue RESOLVED. We’ve tested it in DEV and the solution resolves the problem and doesn’t seem to break anything else. We won’t be able to complete the resolution in our Production environment until after hours as we will have to re-install KB2844286 which will require a reboot and the patch requires at the very least an IISRESET.

Go to http://support.microsoft.com/kb/2872441 to download the update. Note: You will need to run an IISRESET for the update to take effect after installing.

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. 
8. In the Role Members section click the Add button (see below)
9. 
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

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.

Error: SharePoint 2010 Configuration Wizard

I ran into the below error today while installing the April 2012 Cumulative Update (KB 2598321) for SharePoint 2010 Foundation.

I figured I would post the resolution for anyone who happens upon this issue as well and for my own sake, since I’m constantly forgetting the parameter to run. The resolution isn’t specifically just for the April 2012 Cumulative Update. It can be used anytime you see this error.

WARNING: Backup your farm prior to installing Cumulative Updates and running the Configuration Wizard.

What Happened?

Architecture: 2 WFE/APP (load balanced), 1 SQL

Scenario: Installed CU on both WFE’s and ran Configuration Wizard on the primary server first. Attempted to run on the 2nd server and received the error above.

Impact: When the configuration wizard fails, it may then take your WFE offline until you can get this resolved.

Resolution: Run the following PowerShell command on the affected server

psconfig.exe -cmd installcheck –noinstallcheck

 WARNING: Ensure you understand what this command is doing before you perform it on your production servers. Click Here for more information on PSCONFIG.

 

You may need to re-run the configuration wizard to ensure all is functioning but this should bypass the installation check which will disregard the error you saw above.

 

Hopefully this helps you if you have this error.

 

Thank you to @AviSuj for reminding me of these parameters.