wobba
commented
1 week ago Search schemas has to be manually replicated across GEO's and this is what it has always been.
Profiles are a bit different as they are stored for all GEO's. To avoid duplicates you should query one GEO only, and we'd accept a PR to implement this logic to query a specific GEO (https://learn.microsoft.com/en-us/microsoft-365/enterprise/configure-search-for-multi-geo?view=o365-worldwide#sample-post-request-thats-fanned-out-to-some-geo-locations).
Classic search seem to use an undocumented boolean property CrossGeoQuery on it's queries which default is set to false. Feel free to play around with this property and people search.
buildbod
Version used 4.12.2
Describe the bug Classic SharePoint Search includes a switch to include 'Show Multi-Geo results'. Toggling that switch to on results in values stored in RefinableStrings being returned with search results regardless of the geo location of the result.
However repeating the search with PnP Search results in empty values for any user profile not in the main geo.
Expected behaviour Results are returned as per classic i.e. regardless of the geo.
I understand that pnp-search v3 is geo aware e.g. https://github.com/microsoft-search/pnp-modern-search/issues/766
Desktop (please complete the following information):
**SharePoint Search Query Tool As an aside, using the SharePoint Search Query Tool with the EnableMultiGeoSearch set to true returns core properties but does not expose the Refiners.
Given that Classic Search honours the Refinable Strings, it does not seem right to replicate the RefinableStrings across geos. At present they are not replicated e.g.
Main geo
Satellite geo
It is seems that Microsoft have included some logic behind the Show Multi-Geo results feature that is not being picked up in the pnp-search.