3

No, content sources are defined by start addresses and crawl rules. You could try to define a targeted crawl rule, but that would exclude the other content and you cannot reuse the start address. What I would suggest is that you architect your farm so that your search topology can use Continuous Crawl. This brings your index freshness to near 15 minutes (or ...


3

I would also like to add that you can also accomplish this with SQL Table Views. So if you create a custom view within your SQL DB, you can connect to it in BCS using SP Designer as if it was a regular table. My understanding is that if the View is update-able as defined here, you will also be able to add Update controls to it. To add a view as an ECT ...


3

It is actually a bug when you crawl on a site collection in SP2013 evaluation mode. The SharePoint crawler have strange beheviour against these evaluating sites and mess their index altogether. After I fully upgrade the evaluating site to SP2013, reset index, and setup the content sources again, everything works as expected. Thanks and sorry for my careless....


2

To improve your application (to reduce the time difference between new item added/changes and that to reflect on your content Search webpart) , you can try below things: Create a separate content source for your application site collection.(This is to reduce the crawl duration) Configure continuous crawl for that content source.The default interval of ...


2

I would do the following: priorize the incremental crawl with "high" priorize the new content source with "low" limit the requests to the new site in crawler impact rules start the crawl on friday night and pause it on monday - repeat until you have the main chunk indexed (use powershell to automate) With this the impact should not be that hard.


2

Ok i found the problem why the deleted item was still in the index We changed the settings of the following: $SearchApplication = Get-SPEnterpriseSearchServiceApplication -Identity "Search Service Application" $SearchApplication.SetProperty("ErrorDeleteCountAllowed", 1) $SearchApplication.SetProperty("ErrorDeleteIntervalAllowed",0) mentioned in this post: ...


1

Since SharePoint version is not specified, I am assuming it to be SP 2013. You can modify the Search Results web part on the search page to restrict the results based on the content source. Edit the Search results web part and Click on "Change Query". In the Query Text box, use your two content sources, example: ContentSource:"Your Content Source 1" OR ...


1

You can use the stored procedures with BCS, so instead of a single table, you can gather information (Read only) from a result of a query. You need to create the stored procedure in SQL first, then connect to BCS through SHarePoint Designer, then you will be able to create a External Content Type based on that stored procedure. Here is an article that ...


1

This isn't really possible without having multiple farms each with a separate Search Service Instance. I would suggest you basically split out your 1.5TB of content into a separate farm with a dedicated Search instance. You can even use HOSTS entries on the crawl servers so they have their own local dedicated WFE servers for the crawl process to iterate ...


1

Maybe I'm seeing this too late, I had the same problem with the Document Library search box and the solution was re-indexing the all the content at the Search Service Application ( Crawling/ Index Reset ) and running Full crawl. I can provide you full steps if its necessary.


1

You can't, but you can create new Content Sources and remove the start addresses from the original.


1

Yes, It is read only property and I couldn't update it with PowerShell too. I can't imagine any adverse affects of creating a new content source and removing the default one.


1

1: As per your AAM, You need to add https://web.domain.com into your content source. 2: In that case you dont need any server mapping as you are using the FQDN. We have same kind of setup in our farm due to some network issues, So i recommend what we are using. If you click on the edit public url, you will see the FQDN in your default zone and this is ...


1

I can't think of a major reason to go with one way or the other from a query standpoint except maybe convencience: ContentSource contentsource:fileserver ResultSource is a property on your KQL object and needs a guid keywordQuery.SourceId = resultSourceId; Also, content sources can be crawled seperately, if you want that level of granularity. Maybe ...


1

The way search works in SharePoint is to security trim the results before showing the results to a users. Generally you will set up a content source of http://my.com (for the example you provided). If you don't want users to see what is in other site collections use security on the sites. They will not see results from Sites that they cannot access. If you ...


Only top voted, non community-wiki answers of a minimum length are eligible