Forum Discussion
Implementing Cloud Hybrid Search
------------
Update:
After seeing there were replies that I missed, I see a new question about the proxy, so I'll try to contribute *something* new here :-)
On-prem queries SPO using the "Remote SharePoint Index", so there is no SSA Proxy involved.
Instead, to cut over your on-prem to pull queries from SPO instead of the on-prem SSA, you would want to set the result source configure for SPO results to be the "default" result source (instead of "Local SharePoint results"). At this time, you'd also want to remove the "isExternalContent=0" piece so it showed both on-prem and SPO results.
Also, at this time when you cut over, I would suggest moving your primary search center to be hosted in SPO rather than on-premises to get full benefit of cloud hybrid search.
*I can't find the particular TechNet that I had in mind, but somewhere we document that recommendation and will post it here once I find it.
----------------------
By "Federated Hybrid Search", I assume that you're referring to the "hybrid" search that we had before the Cloud SSA was announced (e.g. which was essentially just query federation between on-premises and a remote search index such as SPO ...or vice versa, SPO to on-prem)
For 1, the answer is yes... You can have both SSAs in a single farm (*For administrative clarity and scaling reasons, I would recommend creating the Cloud SSA in its own small farm ...but both SSAs *can* exist in your existing farm)
For 2, both of the SSAs can each crawl the same content source (they are completely independent indexes and isolated administration). However, be aware of the implications...
A) Two SSAs means double the impact on the content repository (e.g. Can your WFEs handle that duplicated load?)
B) With your on-prem federating queries from SPO, you will potentially start to see duplicated items from on-prem.
For example, assume http://on-prem/foo.docx is crawled by both your existing SSA (meaning that item will be in the on-prem index) and by the Cloud SSA (meaning that same item will be in the SPO index). In this case, a query for "foo" from your search center hosted by the on-prem web app will return the foo.docx in the local results and potentially also in the result block for the SPO results.
To avoid this, you should be able to add "isExternalContent=0" to the query template for your SPO result source (e.g. edit this result source in your on-prem SSA) to prevent any on-prem results from being returned in the SPO result block.
For 3, it depends. Is SPO federating queries from your on-prem SSA? If so, you'd probably want to modify the default result source in SPO with the "isExternalContent=0" to prevent duplicate results.
I hope this helps,
--Brian Pendergrass (MSFT)
- Tone Kristin LarsenSep 05, 2016
Microsoft
I think this might be article you were thinking of with respect to setting up the primary search center in SPO:
"Search is fastest when users use search centers that are in the same environment as the search index, so searching from an Office 365 search center gives a better experience." https://support.office.com/en-us/article/Learn-about-cloud-hybrid-search-for-SharePoint-af830951-8ddf-48b2-8340-179c1cc4d291?ui=en-US&rs=en-US&ad=US
:-) Tone Kristin Larsen
- Ali SalihJul 31, 2016Iron Contributor
Hey FormerMember1684 Thank you for your response!
Would you mind eloborating further into your comment about separate farm? I'd like to understand a bit further since I see additional complexity. You meant two farms on-premises;
SP16-Content <----------> SP16-Search <----------> SPO yes?
This way; SP16-Content farm will consume a search service offered by the SP16-search farm while SP16-Search farm has implemented Cloud SSA. Assuming this is the scenario;
1- Doesn't MinRole isolate/de-couple searh in its own container at service level?
2- Both farms need to have additional configurations in order to consume a service from other farm, do you think this isn't bringing in additional complexity compared to single-farm approach?
3- Can we have two Cloud-SSA pointing to the same SPO tenant? This is not directly related to the scenario above, however what I have in mind is; Let's say that I'd like to do On-premises upgrade to SharePoint 20XX Server.... If answer the answer is no, I am locking the Cloud SSA to 1 farm, which almost makes it immobile. Because at times there might be requirements around co-exist. This point might make a case for a small search farm to help to decouple the service completely so that in the future any on-premises farms, still can consume the service without interruption on future upgrade/migrations etc.