In this two-part post I’ll try to explain, compare, and contrast the different search solutions available from Microsoft including SharePoint Server, SharePoint Online, Hybrid SharePoint, Delve, Azure, and Bing. I try to take a business first approach, one I use with my clients, to use search to solve business problems. In part one I’ll start with SharePoint Server and SharePoint Online. In part two I’ll focus on other offerings including Hybrid SharePoint, Delve, Azure Search, and Bing. I hope this helps you to understand what is being offered and the problems the tools offer to solve.
Search as a Business Problem
I have participated in several meetings with customers lately where I am in the room as the “Search Guy”. In the past, in the on-premises world, this meant SharePoint Search. Sure, we could talk about other options, but my clients were Microsoft shops and they used Microsoft technologies. They focused on the platform they knew. That meant that when evaluating new solutions to business problems they would generally gravitate toward Microsoft solutions.
The conversation generally went something like: “We have file shares and can’t find anything.” Every so often I’d get a request for a connection to something that SharePoint did not support out of the box, something outside of SharePoint, File Shares, Exchange Public Folders, Web Sites, Databases and other BCS data, etc. For those situations there are third-party solutions that work and are supported, like the suite of connectors from BA Insight.
That was then.
Search Components in the Microsoft World
As the cloud offerings from Microsoft have grown and matured one thing has become obvious, there are a ton of very smart people working at Microsoft and they are all dedicated to solving business problems like Search. The problem as I see it is many of these folks work on different teams, with different masters to mind and seemingly different variations of search problems to solve. As such, there are several different search solutions that solve different problems. This two-part post strives to shed some light on those solutions and hopefully provide a bit of guidance as to why you would invest time in the technology.
One of the challenges I face routinely as I begin a search project is the daunting task of “getting organized”. Some organizations are so paralyzed by the thought that somehow the process of “getting organized” will take too long or is such a huge task that they avoid it all together. They throw documents from poorly organized file shares into a poorly organized SharePoint or SharePoint Online library and expect that magically the search engine will figure it out. Sadly, it just doesn’t work like that. To get the most benefit from any search service, Microsoft or otherwise, you need to get organized.
In a recent project I posed the question about organization and demonstrated how a 40-hour investment in structuring existing content into document types, departments, and owners would save the company hundreds of hours in employee labor (in looking for or recreating the documents). We did not organize “everything” just the most valuable documents from the most valuable groups. Later, because other groups had seen the quality of the search results yielded by our brief investment, we were invited back to teach them the techniques. Department by department they adopted a very simple organizational approach and the search experience improved dramatically.
SharePoint Server on-premises supports a robust search engine. With the release of SharePoint 2013 and later scalability improvements introduced in SharePoint 2016 the enterprise now has a scalable, flexible, and efficient means to crawl and query content from a wide array of content sources. The main problem I see in most organizations is that IT never takes advantage of SharePoint search and its ability to solve business problems. Search as a business solution is lost in the drive to manage IT, consequently organizations look to their developers to “develop” a point solution. Often those same developers are unaware of the features of SharePoint Search and the associated query API. There are several great resources available to IT, Developers, and End Users to improve the on-premises search experience, provided they have the time and interest to pursue a Search Improvement project.
- SharePoint Search Back to Front – I wrote this course for SharePoint 2013 and it is still applicable to SharePoint 2016. It takes the IT Pro or Search Administrator from the backend Search Service Application setup and configuration through to the front-end user interface modifications that can make a huge difference on organizational adoption of search. You can view my class on Pluralsight – SharePoint Search Back to Front.
- SharePoint 2013 Search Development – Scot Hillier has produced a fantastic course for developers that is available on Pluralsight. His course complements mine in that it demonstrates how to construct User Interfaces and Apps that use the SharePoint Search API. He is a fantastic instructor and his teaching style is very easy to follow. You can view his class on Pluralsight – SharePoint 2013 Search Development.
- Search Explained – Founded by my dear friend and fellow MVP Agnes Molnar, SearchExplained.com is a site dedicated to helping users improve the end user search experience. It has a wealth of articles and tools available for free. Search Explained also supports a Yammer network where folks like me answer search related questions to anyone willing to ask. In addition to the wealth of free resources, Agnes offers online courses that will jumpstart your search education, no matter where you are starting. She does a great job from helping you get organized through to executing your search project.
SharePoint Search is tremendously powerful, feature-rich, and extensible. There are very few business requirements I have had to turn down for clients that use SharePoint Search. The ability to connect to many different Content Sources, the configurability of Result Sources to scope and customize the result set, and the flexibility of Query Rules allows me to provide my clients with a tailored search experience that rivals custom applications for a tenth the cost of building and maintaining a custom application or separate search appliance. Add to that the ability to customize the Search Results user interface with display templates and you have an incredibly powerful platform for business search. I think the strength of SharePoint Search lies in its configurability and flexibility.
The two main issues I run into managing and maintaining SharePoint Search on-premises is the need to support an on-premises SharePoint Search infrastructure and a general lack of understanding of how SharePoint Search uses resources. Following one of my sessions I had an attendee ask me how to “throttle” Search. I asked “Why?” and was told that “Search is killing my servers!”. I put on my consultant cap and asked for more detail. He told me that with continuous crawls all his search servers were running around 80-90 of CPU. I asked if the farm was slow or if the users were complaining, “No, but none of our other servers use so many resources. The more RAM and CPU we give it, the more it takes!” Here is a case of the SharePoint Search Service doing exactly what it was designed to do, yet he had never seen this in “other applications” so it must be bad! My response was that fresh indexes are good for business.
The differences in SharePoint Online Search are visible everywhere in SharePoint Online except the classic search site. Every SharePoint Online tenant is provisioned with an Enterprise Search Center under the <tenant>.sharepoint.com/search managed path. This is where the similarities between SharePoint on-premises and SharePoint Online end. The team at Microsoft responsible for the Search user interface have made investments in “other search experiences” with an eye toward the end user. They have consolidated and optimized the search experience beginning at the “SharePoint Home” page and still provided links to get the user to the enterprise search center.
Figure 1 One of the new “Search Experiences” being introduced in SharePoint Online
Under the hood, SharePoint Online Search is very similar to that included in SharePoint 2016. The biggest difference is the scale at which Microsoft is running search. No ordinary organization has the budget, man power, or expertise to run a SharePoint search farm at this scale. The index freshness values for SharePoint Online are staggering. I routinely perform demonstrations where I see sub-five-minute index times and I have never seen it take longer than 10 minutes. The other big benefit to SharePoint Online Search is that if you have the skills to work with SharePoint on-premises you can transfer all that skill and investment into SharePoint Online Search. The technology and techniques are the same with a few minor differences.
SharePoint Online search is that it is limited to the content in your SharePoint Online tenant. Administrators cannot add new Result Sources to crawl. This limitation can be overcome by using a Hybrid Search configuration (discussed in Part 2). Other limitations have been introduced with the new Search Experiences I mentioned above. Today, we have no commitment from Microsoft that any of the new search experiences will be configurable or customizable. For me this is a bummer. It means that many of my customers most valuable resources are at the mercy of the closed algorithm and closed user interface. Their investments in custom display templates and metadata that yield a wealth of information may be left behind.
In my next blog, I will discuss how organizations can get past the limitations of a SharePoint only approach and look at additional solutions from Microsoft.