Display Comments and Likes in content search webpart

[SOLVED] Instead of relaying on the search crawler for the #Comments field, I simply added the following line in the Display Template and that works with continous crawling:
_#= ctx.CurrentItem.NumComments =#_
[/SOLVED]
 
I want to show both number of Likes and Comments in the News webpart, which I have built using Content Search and my own custom Display Template.

 

The Likes is easy, it already exists. Just select “LikesCount” in the Property Mappings List (Note: I have added own lines in the display template, hence the extra rows below):
The number of comments are not included though, so that property needs to be created in the Search Schema. In SharePoint 2010 and in a Content Query Web Part, I referred to this field with #Comments. But that does not work in 2013.
Go to Search Application on CA, and to Search Schema. Add a new Managed Property, I called it just “NumComments” and map it to the column “ows_NumComments”. Configure it like this:
In the display template, I have used Glyphicons to display a Like button and a Comment button. This is my code for the “Like and comment” part of the news (I have removed the <> from code and replaced with [] ):
[div class=”cbs-largePictureLineCustom ms-noWrap”]
[span title=”_#= $htmlEncode(line4) =#_” id=”_#= line4Id =#_”]_#= likesCount =#_  [/span]
[span class=”glyphicon glyphicon-thumbs-up”][/span]
[span title=”_#= $htmlEncode(line5) =#_” id=”_#= line5Id =#_”]_#= line5 =#_ [/span span class=”glyphicon glyphicon-comment”][/span]
[/div]
When running continuous crawling, the Likes showed up within a 3 minute interval (I have set that interval using Powershell cmdlet Get-SPEnterpriseSearchServiceApplication and continouscrawl), but the Comments never showed up unless I was doing a Full Crawl.
So to enable the number of comments in the continuous crawl, click on the “ows_NumComments” link that is displayed in the Search Schema:
And deselect the “Include in full-text index” (this turns out to not help anyway which you will find out below):
But the Comments still did not show up in the web part, (unless I did a Full Crawl).
So I did a Reset Index. Ran a Full Crawl, to make sure that my changes above had been implemented. Still new comments are not displayed unless I run a Full Crawl.
Looked in the Search Schema again, but this time I clicked on Crawled Properties. Found a difference between the field ows_Comments and ows_LikesCount. The later had a mapping, which ows_Comments missed. So I added the following mapping into the “ows_NumComments”:
Started a Full Crawl again to implement the changes.
Added a new comment and waited for the continuous crawl/incremental crawl to pick up the changes, but it does not show in the content search web part. Only when I do a full crawl. Don’t know if it has to do with the NumComments field being a Lookup field? If you look at the column properties on the blog site (the News are built on a blog site template) then this is all the info you get:
The column is not created as a Site Column, but a local in the Posts library of a blog site.  The only solution I could think of, and I don’t like it but what to do, is to create a new Content Source with only the link to the comments in it and set that to Full Crawl each 3 minutes. Don’t know if this will work in the long run, but for now it’s good enough.
 

Hide Conversations from Search

If you want to hide the “Conversations” options from the dropdown menu that is shown after the Search box, the easiest way is to CSS hide it. Set the following class to “display:none”.
#ctl00_PlaceHolderSearchArea_SmallSearchInputBox1_csr_NavDropdownList div:nth-child(3){display:none;}
 
Then you want to remove the same option from the Search center page (results.aspx) also.
Edit the Search page (in the Search center)
Edit the Search Navigation web part
Click on “Search Settings Page”
Select “Conversations” and “Delete”
Done.

Search hangs on “Starting”

I think I know why this happened from the beginning. I got the warning message in Health Reports about having Admin accounts running the app pools or services. So I have corrected one account and now all these messages are gone. But that caused a new problem with Search Service. The error message was:

“Unable to retrieve topology component health states. This may be because the admin component is not up and running.”
 

Googled it, and found lots of articles about this error. Most suggestions was about installing hotfixes, adding permissions directly in the SQL db’s, changing environment variables, installing latest win updates etc etc.

But I had a feeling it had more to do with the accounts running the Search services or application pools. I had changed some of these from farm account to a specific service account, for security reasons and what MS recommends. But, after having changed back the SharePoint Search Host Controller to the farm account, (Go to “Security”, “Configure service accounts” and select the “Windows Service – Search Host Controller Service”, make an IISRESET afterwards) and all started working instantly.


Maybe not recommended, but I will keep it running like this. The message in the Health Analyzer has not come back so, so far so good.

Create your own search control

I was looking for a way to get rid of the icon gosearch.gif in the Search Area in SharePoint:
There is no way to replace the image with a css class, the only thing you can do is hide it with a new class that is called td.sbgo img and add the display:none to it.

So you must create a new feature, which is really easy.

Copy the OSearchBasicFeature folder in the Feature directory in the 12 hive.

Rename to whatever you like, LisesSearch is fine =)

Edit the feature.xml file and add a new GUID (link here)

Edit the SearchArea.xml file and add the path to your own search button (I put an image in the IMAGES folder, actually I created a new folder beneath it where I put my own search image):

Rename the Control Id in this file to something else like “LisesSearch”

Install and activate the feature

stsadm -o installfeature -filename LisesSearchfeature.xml
stsadm -o activatefeature -id “YourGUIDhere” -url http://yoursitehere/

Now, in your masterpage just edit the Control Id of the aspcontentholder “PlaceHolderSearchArea” to your own Id (in this example LisesSearch).
Now (after some branding on the sbcell and sbgo classes) the search should have your own buttons:

Error 6398

This is my platform:

A server farm with one SQL Server and one WSS 3 SP2 server (win server 2003). I have installed Search Server Express 2008 with Swedish language packs. Everything is working fine, the search is up and running and all. But, in Event Viewer I got this error message each time the indexer started (and I hate to have error messages, it is so disturbing! I want a clean log!):

Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Timer
Event ID: 6398
Date: 2009-07-10
Time: 14:30:01
User: N/A
Computer: XXX
Description:The Execute method of job definition Microsoft.SharePoint.Search.Administration.SPSearchJobDefinition (ID aeb1e8f1-9341-417b-ab76-9442095f1019) threw an exception. More information is included below.

Retrieving the COM class factory for component with CLSID {629DA12E-9AD5-4FEC-B886-42C5982C5109} failed due to the following error: 80070422.

Hm. Looked in Central Administration on “Services on server”, and both services were started there, that is Office Server Search and WSS Search. BUT, when I looked in Services (from the Control Panel) then the “Windows SharePoint Services Search” was disabled. Started it, and now all errors are gone.

Event 2436 returns no search results

All of a sudden the search stopped working on a MOSS 2007 server. Looked into Event Viewer and found the error message:

Event Type: Warning
Event Source: Office Server Search
Event Category: Gatherer
Event ID: 2436
Date: 24-04-2009Time: 13:29:31
User: N/A
Computer: DKxxx001
Description:The start address <http://xxx> cannot be crawled.
Context: Application ‘SharedServices1’, Catalog ‘Portal_Content’
Details: Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (0x80041205)

No changes have been made to the server, no accounts have been locked out or password has changed. First thing I did was to restart the Office Sharepoint Search Service. Did not help. Re entered the password for the Default Content Access Account. Did not help. Googled it. Found an article on Microsoft that you should enter the following in your registry:

1) Click Start, click Run, type regedit, and then click OK.
2) In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa3)
3) Right-click Lsa, point to New, and then click DWORD Value
4) Type DisableLoopbackCheck, and then press ENTER
5) Right-click DisableLoopbackCheck, and then click Modify
6) In the Value data box, type 1, and then click OK
7) Quit Registry Editor, and then restart your computer (now that I did not have to do! It worked immediately)

That helped!! Now the full crawl is crawling and all is well. Now I can really enjoy todays after work in the sun :=)

No results matching your search were found

A search on “All sites” returns results, but when you select the “This site: xxx” no results are returned:

Match your default zone url in Alternate Access Mappings with the url used in the Content source, then you will fix this issue.

A clarification: This issue concerned a MOSS server, not a WSS installation.

Part 2: Search issues

This is the rest of the story regarding Search issues

Problem: the customer has a server farm (the platform is one SQL, two WFE with MOSS 2007) and NLB running. When accessing one of the servers, the Search Box is missing. This is what the customer reported to me, and where my troubleshooting started.

Summary: Resolving a database schema mismatch after applying Security Update KB 956716

So, I had tried to reset the content index on the WFE in the server farm. But that crashed and I got into a real mess where I restarted the search services, reset the passwords on all search accounts, etc. Nothing helped me so that I could perform a Full crawl again. I got a lot of errors within Search Settings and finally what happened was that when I clicked on Full Crawl it only jumped back to “Idle”, so nothing could trigger the Full crawl.

Then I discovered the real issue: on the WFE where Search box was disabled, a patch for SharePoint had been installed. No one knows why that patch was installed, probably it has been downloaded and installed along with some other updates. So, there was a mismatch in patches since the KB956716 only was installed on one server and not on the other (as you can see, it is divided into three instances – strange):

So, I ran the Sharepoint Configuration Wizard. That was successful, and the search box came back! Success I thought and ran a Full Crawl. Everything was working perfectly. The morning after I tested the search again… No results!! Hm, what had happened during the night?? Looked through Event Viewer and there were some error messages saying that there was a database error:

Event Type: ErrorEvent Source: Office Server SearchEvent Category: Gatherer Event ID: 10036Date: 18-03-2009Time: 14:00:07User: N/AComputer: Dxxxx001
Description:A database error occurred.
Source: Microsoft OLE DB Provider for SQL
ServerCode: 4060 occurred 1 time(s)
Description: Cannot open database “SharedServices2_Search_DB” requested by the login. The login failed.

So I installed the kb on the search server as well, but the first time the server hung and we had to restart it. Then I ran the kb installation again and success this time. Restarted the server. Ran the configuration wizard. and it was successful. Started CA and Search settings and tada, there was a new link, Search Administration which is the same link that you get when you install the infrastructure upgrade.Performed a full crawl…. and yes! It started!

Conclusion: always make sure your server farm has a “patch match” 🙂 And always run the Config Wizard after a patch has been installed, then all will work fine.

Part 1: Search issues.. again

Search had gone to status “Computing ranking”, happens every now and then. Usually a Full crawl makes the index work again, and status changes to Idle, but sometimes you have to perform the “Reset all crawled content”. Did that on a server yesterday, but this time the action hung and I got an error message due to a timeout in the connection. So, I opened services and stopped the Windows Sharepoint Search, worked fine. Tried to stop the Office Server Search, but that resulted in an error message due to a timeout….. Yuk. To do something and trying not to panic, since this is a production environment (of course…) I started the WSS Search again – worked. But the service Office Server Search still had the status “Stopping”. And you cant stop it, not in Services and not in CA under Services on server. Now when I click on “Search settings” in CA, I get the message “The gatherer is shutting down”. And there you go… stuck.
So my plan for tomorrow is the following:
– First, check out the Timer Job Definition to delete it there (if it is listed)
– Edit all passwords and re enter them on Services page and on the Services in Control Panel
– Make sure that the accounts are admins where they are supposed to be Admins
– If none of those works, I will setup a new SSP and associate my web apps to that. That should do it.
Now, I need to find out why the search hangs sometimes and gets into the “Computing ranking” state. I have had that problem on many servers, it might have to do with performance, timeout against the backend, password changes on the service accounts, and so on…
I hope that my fix list will be successful tomorrow!

Search and Basic Authentication

We wanted to add a Default Domain so that the users did not have to enter a domain name to logon to our site. Did that, using Basic Authentication and added our domains on the IIS site. Fine, worked perfectly – the user only had to enter the username and password to logon. Fine. But…. when you win some you loose some… then my Search stopped working and Event Viewer filled up with the following error:

Event Type: WarningEvent Source: Windows SharePoint Services 3 SearchEvent Category: Gatherer Event ID: 2436Date: 2009-02-09Time: 09:15:02User: N/AComputer: xxxDescription:The start address cannot be crawled.
Context: Application ‘Search index file on the search server’, Catalog ‘Search’
Details: Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (0x80041205)

Riiiight. What is your first thoughts on this error? Well, you update all passwords on the search account. On the services, on the Search settings, you check that the account has rights on your SQL server and so on… Until you realize that is has got nothing to do with permissions on the account. Must be something else that stops the crawl from working.

So I extended the site and used Windows Authentication. Search is working! So.. after endless testing back and forth it started to clear for me what was wrong.. Basic Authentication cannot be used as Default zone? During this weekend I came up with a solution that I tried today and that was successful! I did the following:

I have a web application on a site with SSL. Authentication provider is set to use Basic Authentication and on the IIS site I have entered a default domain.
I extended that web application to a site with Windows Authentication and select a zone for it, I chose Intranet. Now this is the site that the search will crawl, otherwise it cannot authenticate and it gives you the 2436 error message.
So therefore this site must be in the Default zone.
Enter Alternate Access Mappings and change places for your Default and Intranet Zone.
IISreset
Wait 5 minutes (or whatever timer you use for the indexer) and… wow!
Search is working!!!
And since our load balancing servers are using the site with SSL, then I do not have to use a host header on any of the web applications – it uses the 443 port anyhow.

Now the challenge is to install Search Server Express 2008 once again, as a single server deployment. To be continued….