We run a classic JavaScript app on multiple tenants on SharePoint online. The app uses the Microsoft.SharePoint.Client.Search.Query.KeywordQuery to search for documents within the site collection where the app is installed. On one of the systems we get the error:
Microsoft.Office.Server.Search.SubstrateSearch.SubstrateSearchException:
Remote executors failed, local failback not allowed.
Despite the specific words in the error message, I was not able to find any documentation about its meaning. When I copy the search string used in the SP search field the search works. Any clues what could be the cause?
Any developments on this? We just started seeing this same error in one dev environment but not another, despite running the same code.
I have the exact same problem, but if I include "-contentclass:STS_ListItem_DocumentLibrary" in the keyword query it works, but since i need items from document libraries this wont help me.
We have only seen this issue one one environment, I am not sure how to fix it. It looks like it is having issues with document libraries specifically, unless i include a some text it also should search for (besides the keywords). If i didn't know any better i would almost say it was some kind of overflow, but that just seems far fetched, and we do have limits on the query anyway.
Update:
Subsequently if I wrote a keyword for a specific library like ListId:73C91192-89CD-4C06-A322-388CEAE456ED instead, it also works
we just recently started to see this same issue.
In our case we were using a Classic SharePoint Online site, with the search web parts on it. The search results web part had a number of different Hit-highlighted managed properties that it was trying to bring back. One of these properties was "Topic". I checked the search schema and for some reason, this managed property had disappeared. Removing this property from the search results web part fixed the page and search results web part.
No one had touched our search schema in a long time so this property had simply disappeared. Definitely seems like search schema updates are causing issues.
Hit-highlighted properties
Does anybody have some usefull information or pointers on this issue? We just came across this issue on one tenant for one specific user. We have a multi-tenant app that executes a search query looking for document libraries with 3 conditions:
We do use the ContentClass:STS_List_DocumentLibrary condition as we are looking for document libraries
External content specifier: "-isexternalcontent:1"
Generic search term: just a single word
As mentioned we get this error on one tenant when one specific user executes it. I can't reproduce it with other user accounts. Since we are providing a multi-tenant SaaS we are afraid this will start popping up for our customers..
Related
I am using Azure search where it creates index on my database tables and shows results as expected.
Now I have a requirement where I need to find-out what are the words or items users have searched most or what was the pick time for search.
Is it possible to find any such reports with Azure Search?
Either by its portal or using the API or Code?
I'm on Azure Search team, thanks for using the service. Currently it's not possible, however, we understand the importance of this feature and we're working to deliver it. No exact dates yet. For now, you'd have to collect and aggregate the information you need on the client side.
For feature request like this, feel free to use our User Voice page to help us prioritize work: http://feedback.azure.com/forums/263029-azure-search
We have a special situation at our office where we "close" off a site collection when a project is complete. Our architecture is setup such that each project in play is it's own site collection. When the project is complete we close the project in SP by setting the site collection to read-only.
Part of our business would like to still view the closed site collections, but doesn't want to go through a list of them (I mean excel spreadsheet or some other external form of tracking), but instead wants to do it from a page in SP. Our solution is to modify one of our other solutions (search query web part that finds all site collections they belong to) and only search on closed site collections.
I know how to determine if a site is ReadOnly or not in Powershell (#spSite.IsReadOnly), but that isn't going to work here and going through the properties in search I couldn't find anything that jumped out at me to do this. Does anyone know how to return ReadOnly site collections in a Search Query Web Part?
Thank you.
I know of a managed property called: SiteClosed but I haven't got the slightest idea what it does. Looking at the name this might be the one to start with.
If this doesn't work I'm afraid the only other option is to create a custom Web Part...
I am doing an in place search in a document library and results are being returned just fine. However, some users are reporting seeing the following message:
Some files might be hidden. Include these in your search
I also receive this message at random times for different searches. There seems to be reports of this on various boards with no real answer. Anyone know why this message would occur?
This may relate to the Search Service Settings > Content Source in Central Admin. Ensure that the addressers are correct and that the crawl have the same entry as you do. Normally you want to point the url to the default zone.
When done, reset the index and start a new full crawl.
We are currently using a number of open source and commercial products to store different type of information (in our internal network). All these products come with their own repositories (usually a database) and their own search capabilities and store different type of information.
Currently the list of products is as follows:
Wordpress
Jira
Confluence
Sharepoint
Dynamics AX
Moodle
The problem we are facing is that when one needs to search for information, one needs to login into all these different systems and execute a search on each one.
I Googled for "search engine frontend", "meta search engine", etc. but i was not able to find something obvious that solves our problem. At this point, i have to say that we are not interested in building one "central repository" to be searched, but instead we are in need of a frontend that will accept the query from the user, "package it" to the format that each of the individual search engines understand, receive the respone (JSON or XML) and present it to the user
Any suggestions on how we could solve it?
Your strategy is right: If you are not interested in building a central index, you will need an application that accepts the query from the user, converts it to the format that each of the individual search engines understand, receives the responses and presents them to the user. This is exactly what a meta search engine does. Even if you use a framework (e.g. Carrot2), much work will probably remain to write those query and result transformers, and you will probably experience slow results because the meta search can never be faster than the underlying search modules of the components you search through.
Instead of querying each backend separately you can put your data into one backend.
You could export your data to a Apache Solr server and use a frontend like CorePages, http://www.corepages.biz . You could add a backlink to your data so you can directly jump to your search result entry, f. e. a Jira Ticket or a wiki article.
Does anyone know if it is possible to display a prompt to a user/administrator when activating or installing a sharepoint feature?
I am writing a custom webpart and it is connecting to a separate database, I would like to allow the administrator to select or type in a connection string when installing the .wsp file or activating the feature.
I am looking inside the FeatureActivated event and thinking of using the SPWebConfigModification class to actually write the connection string to the web.config files in the farm.
I do not want to hand edit the web.configs or hard code the string into the DLL.
If you have other methods for handling connection strings inside sharepoint I would be interested in them as well.
Unfortunately there is no way to swap to a screen where you can get user via the feature activation process. Couple of comments for you:
I'm assuming the connection string is going to be different for every installation, so there is no way you can include it directly in the Solution.
I'm assuming that you couldn't programmatically construct this during installation.
Therefore, you need some way to get user input. Here are a couple of options:
It could be a web part property, though this would mean setting it each and every time the web part was added, and you would need to then maitain those settings individually.
You could build out your own _layouts settings screen (good post: http://community.zevenseas.com/Blogs/Robin/archive/2008/03/17/lcm-creating-custom-application-page-and-using-the-propertybag-more-detailed.aspx), and from there users can maintain the property, storing it in either the Web Property bag, or inside the Web.Config. I try to avoid using the Web.Config where I can, but if you do wish to go this route then MAKE SURE you use the SPWebConfigModification class (Read this great blog: http://www.crsw.com/mark/Lists/Posts/Post.aspx?ID=32)
Finally, a technique I often use is storing configuration information in a SharePoint List. Chris O'Brien has a great framework for that here: http://www.codeplex.com/SPConfigStore
Hope that helps,
Daniel
Sounds good. I will look at these possible solutions.
I do not think #1 will work since I am deploying multiple webparts inside a single solution which all use the same connectionString.
#3 sounds like a very clean solution. I see the config items are cached so it looks like if I need to store a connection string, I will not be hit with a SP lookup each time I need that string.
While searching for a solution I did stumble across another method.
If you dig around their code, I looks like they have created an installer that accepts application specific values, adds the values into a FeatureTemplate.xml file and passes them to the SPFeatureReceiverProperties object in the Reciever.
I was about to start tackling this method, but I think #3 would be better.
Thank you,
Keith