I share hereby all the considerations I should have taken before even starting to implement Cloud Hybrid Search. As always I dove into the technical, and from my point of view, more interesting parts of a project. This project was no different.
Take the following facts into account before even remoting to your SharePoint servers.
This is a blog post of a multi-part series. You’ll find the first post here.
Our setup was pretty standard: One integration environment (let’s call it INT) and one production environment (PROD). INT and PROD consist of two web frontend and two backend servers. Both environments are joined to the same AD (we name it “engineererAD”).
This means our servers from both environments are joined to engineererAD.
Prior connecting a SharePoint farm to a O365 tenant, we need to synchronize the local AD with the Azure AD. This is a 1:1 connection. Each local AD domain can be connected to only one Azure AD. An Azure AD can’t host multiple local ADs as well.
This means: OnPremise staging with INT and PROD is useless for our hybrid setup. We connect the engineererAD to Azure AD and connect PROD to O365 that uses this same Azure AD. We can’t connect INT to the same Azure AD. Period.
Don’t worry, that’s not a problem at all. The critical system chances are done by Microsoft and we won’t need a staging anymore. It could have been usefull when setting up the hybrid environment. But after that is done, the necessity for an INT is gone. To test the SharePoint Online Search Center you could just create a new site collection with the Search Center template. After you implemented and tested everything, you could transfer the result pages to the standard search center in SharePoint Online.
Crawling with Cloud Hybrid Search
During the setup of the Cloud Hybrid Search, we will have two Search Service Applications. Both service applications will crawl the same content for a while – until we can delete the old Search Service Application. This means double the workload on your search servers.
To solve this issue, try to play with the crawl schedules. You could, for example, crawl just one content source twice (once per Search Service Application), verify the working of it in the Hybrid Cloud Search and then disable the crawling in the old Search Service Application. Your users will then need to search in the cloud search center to find content from this particular content source.
Another approach would be, to just crawl the content once with the Cloud Hybrid Search Service Application and implement everything you need. And when you verified the working of all content sources, enable the crawl schedules on the new Cloud Hybrid Search Service Application and disable those in the old Search Service Application.
Costs of Cloud Hybrid Search
I don’t meant to talk about exact costs. Still, the hybrid scenario is the most expensive one, until you can decommission servers onPremise.
Consider what you want to sell to your internal customers too. It might be best to not customize SharePoint Online sites too much. Microsoft will change some features you depend on anyways. Sometimes faster than you think.
I suggest to sell SharePoint Online as a service, where your users are mostly free to do everything they want and can. But they shouldn’t expect support from IT for they custom solutions.
Don’t search for PowerShell CMDlets to change the search schema. You will configure refiners by hand – there are no CMDlet for it.
DocSets lack of PowerShell support as well.
To publish content types a customer of mine developed a script that invokes web requests as if he would click the “publish” button on the content type page.
Those are some considerations to take. None of them stopped us in implementing Cloud Hybrid Search, because the drawbacks of those are just a pain in the ass during setup. After the setup you won’t miss those features anymore.
So, don’t let it stop you. But calculate a little more time for the Cloud Hybrid Search setup as you intended initially. Good luck!