Search Drives Adoption and Engagement

The interwebs are alive with blog posts and sometimes not-so-cleverly hidden vendor messaging describing the many ways that you can increase your SharePoint adoption. As the shift in attention moves from IT Pro to business capabilities, adoption and engagement (or some variation of them) are quickly becoming the most discussed topic in the community, which really isn’t any surprise. What fun is it to throw a big (expensive) party if nobody comes? And yes, getting your organization to use the platform which you spent so much time and effort to deploy is as much about building buzz, running contests, and constantly educating your users as it is about building and deploying the platform. Yes, ultimately, you need to deliver the features and business value — but even then, you’re going to need to employ some degree of salesmanship. No matter how solid the solution you deploy, adoption takes work.

So how do you get them to stay? A cool splash screen? A dancing kitty? Bribery?

imageThe best way to get users to stay is to make it effortless for them to get what they need. I’ve often written about change management and governance, which are important in the ongoing support of any healthy SharePoint environment. But those strategies become important once the system is in place — and are irrelevant (well, for the most part) once people are using the system. The problem is, as with everything in this world, first impressions are everything. If your users come to SharePoint and it’s not faster and simpler to operate than what they’re currently doing, they’re just going to go back to doing what they did before.

Search in SharePoint has always been more of an art than a science. A couple years back, I took a workshop with my friend and BA Insight CTO Jeff Fried (@jefffried) to learn more about the technology behind search, and while I took copious notes and understood much of the content shared, I quickly realized that a search expert I am not. But the concepts are fairly straightforward, and worth sharing: crawl, index, query, rinse and repeat. The challenge is getting the terms right. With SharePoint 2013, these core concepts are pretty much the same as previous versions, but there were some other fairly noteworthy features that were added. For example, an analytics processing component was included that allows for search specifically by activity.

I know there is new capability coming with SharePoint 2016, but often people are still unaware of what is available today — and taking advantage of the current search capabilities will greatly impact your user experience today, i.e. adoption and engagement.

Similar to previous experience, the crawl component goes through the all the content sources (web sites, file shares, SharePoint, profiles, etc.) and temporarily stores all of the information in the temporary crawl database. The crawl database contains detailed information about items that have been crawled such as last crawl time, crawl ID, and type of update (full or incremental). If there is a large amount of content to crawl through, you can simply add more crawl components to do the work.

Once the items have been crawled, content processing takes the crawled information and feeds it into an index. The index parses the documents using iFilters, and then transforms the crawled content into indexed content. There is also a separate link database that writes the information about the links and URLs associated with the information.

The analytics processing component has two separate components itself. Search analytics goes through the crawled items to find activity information such as links, related people, and metadata. Usage analytics contains information like views on an item from a front-end event store. The processing component then returns the information to the content processing component to include them in the search index. Default usage events are things like views, recommendations displayed and recommendations clicked. Results from usage analytics are then stored in the analytics reporting database. Along with the new analytics processing comes some new default reports such as popularity trends and most popular items.

The index is different as well in 2013. This time around there is just a single index, but the partitions can be stored across multiple servers. The upside is it’s easier to add a new server to share the load, but it’s also difficult to remove one, should you need to. There are also separate index components and partitions. Each index component takes in the information from the content processing component. Queries are then sent to the index replicas from the query processing component. As a general rule, you should add one index partition per every ten million items and a replica should be created for each partition.

The last piece of this puzzle is the query processing component. This little guy sits between the search front-end and the index component. The purpose of the query processing component is to analyze and process the search queries and results. Once done, it submits the query to the index component and then returns it to the front-end.

All in all, it’s really not as complicated as it sounds. If your search is going slower that you’d like, add more horsepower. For faster crawl times, add more crawl databases and content processing components. If the results are taking too long to be returned, replicate the partition. Or in the case of a larger farm, split the index into more partitions. To increase the availability of query, create an extra query processing component on different application servers.

So why go to all the trouble of learning how all of this works? Because search is the backbone of SharePoint and, as I mentioned up top, a key ingredient in making SharePoint perform under the scrutiny of discriminating end users. How do we get adoption to where we want it? Configure a fast, accurate, efficient search so your users can find what they’re looking for.

Christian Buckley

Christian is a Microsoft Regional Director and Office Servers and Services MVP, the Founder & CEO of CollabTalk LLC, an independent research and technical marketing services firm based in Salt Lake City, Utah, and CMO of, a blockchain-based video technology company.

2 Responses

  1. Rene Modery says:

    While there’s a lot in the article I agree with, I was not quite happy with how the post ended.
    “How do we get adoption to where we want it? Configure a fast, accurate, efficient search so your users can find what they’re looking for”
    I think Search is only a piece of the puzzle here, with e.g. content quality being another (and also being the one linked most closely to search). I’m sure that if I searched the large archives of Buckley Content I’d find some relevant article on that topic as well. And I also think that it might just be a small semantic issue with how your article ended (again, I think I’ve seen some other adoption&engagement content from you)

  2. Admittedly, my closing may have been a bit hasty — but in context to an article on the importance of search, it’s not that I am wrong, but only that I swept past other important factors for adoption. Agreed. There are many different factors, of which search is a key ingredient. Because we’re talking here specifically about knowledge management and collaboration (SharePoint), search is a keystone to a successful deployment. You might have a well-constructed plan, training strategy, the latest technology, etc etc….but if people are unable to find their content (the RIGHT content, quickly) then the rest doesn’t matter, and they won’t adopt.

Leave a Reply

Your email address will not be published. Required fields are marked *