Bill Baer /bɛːr/

STUB Verticals A search vertical only shows results of a certain type or from certain content. Examples are Files or News. By default, Microsoft Search shows the verticals All, People, Files, Sites, and News. You can add search verticals that are relevant to your organization that represent content indexed with one or more Microsoft Graph connectors. Microsoft Graph connectors The ‘All’ vertical contains high value entities to include, but not limited to:

Last month we shared changes we’re making to Microsoft Search in SharePoint Online as we continue our journey of bringing Microsoft Search to your favorite Microsoft 365 productivity apps and services. As a result of this announcement, we’ve seen questions as to whether FQL (FAST Query Language) is being deprecated as a result of these changes. The simple answer is no, FAST Query Language is not being deprecated; however, there are some features of FAST Query Language that are being deprecated:

As we continue to ease into working remotely, search has evolved beyond its traditional perception of providing simple utilitarian value, to now serving as a proxy to person-person interactions, quick hallway conversations, and unstructured meetings – effectively search has become the “digital water cooler” for many businesses. The ability to find information in context has become increasingly important, not only because we’re more distributed, but so is information; however, you need to be able to not only discover information in context but have the assurance that the results are the most relevant to you and your task.

Microsoft Search is a new cohesive search capability in Microsoft 365 enabling you to find, command, navigate and discover items across your organization’s network of data, transforming your search bar into a resource for collective knowledge. An AI-powered insight engine that connects content across Windows, Office apps, Office.com, SharePoint, OneDrive, and third-party ecosystems to surface relevant, personalized results, whether it’s a recent chat, people card or a document a coworker shared.

Search has become the primary means in the Enterprise for surfacing and locating information, as a result, it has become a mission critical component of SharePoint deployments. The rise in adoption of SharePoint 2010 in organizations has led to more customers seeking to leverage the benefits of the new search architectures, whether Enterprise Search in SharePoint 2010 or FAST Search Server 2010, as part of their topologies. In either scenario…read more on the SharePoint Team Blog.

Understanding search is the primary means in the Enterprise for surfacing and locating information…as a result, it has become a mission critical component of SharePoint deployments. The rise in adoption of SharePoint 2010 in organizations has led to more customers seeking to leverage the benefits of the new search architectures, whether Enterprise Search in SharePoint 2010 or FAST Search Server 2010, as part of their topologies. In either scenario, customers are faced with a decision on how to accomplish upgrade and accommodate their end users.

I was just reading Todd’s post on preparemove, and he does a good job of covering the changes in profile synchronization and related GUID reset/reassignment introduced by the application of the Infrastructure Update. There is one significant problem this change mitigates, specifically for those looking for a level of search redundancy through a dual-crawl architecture. In most scenarios where a dual-crawl architecture is implemented, an Office SharePoint Server Search instance in the primary datacenters crawls its localized content, and a separate, unique Office SharePoint Server Search instance in the secondary datacenter crawls the content in the primary datacenter.

A new whitepaper has been published on protecting the Microsoft Office SharePoint Server 2007 Search components. The whitepaper includes scripts to enable Data Protection Manager 2007 to backup and recover the Microsoft Office SharePoint Server 2007 Search components and a detailed set of instructions on configuring Data Protection Manager 2007. The sample scripts provide guidance on backing up the search index, Search and Shared Services Provider databases. Read more…

The Microsoft Filter Pack for search has been released enabling critical search scenarios across a variety of Microsoft Search products including SharePoint Portal Server 2003, Microsoft Office SharePoint Server 2007, Windows SharePoint Services 3.0, Search Server 2008, Search Server 2008 Express Edition, Exchange Server 2005, SQL Server 2005/2008, and Windows Desktop Search 3.1/4.0. The Microsoft Filter Pack provides iFilters for the following file type extensions: .docx (Microsoft Office 2007 Word Document) .

I was just looking at the new Halo 3 skin recently applied to Tafiti and was very impressed. For those who’ve never heard of or much less used Tafiti. Tafiti is an experimental Microsoft search front-end designed primarily for research projects spanning multiple queries and sessions through a variety of visualization, storage, and collaboration/sharing presentation and management layers. Tafiti uses a combination of Live Search and Silverlight to both power and render results.

One of the most critical components of Microsoft Office SharePoint Server 2007 to many businesses is search and often is a key component of business processes. To ensure consistent and recoverable content is available to end-users, it becomes necessary to periodically backup the search components in the event of a catastrophic failure or issues requiring the rebuilding of the search component. Since re-crawling all content sources may not be practical or efficient in many cases, Microsoft Office SharePoint Server 2007 has streamlined the search component backup and restore process.

In a recent conversation with a colleague I was asked the differences between Windows SharePoint Services 2.0 and 3.0 incremental crawls and the availability of results and thought I would share and explain briefly the differences here: In Windows SharePoint Services 2.0 when an incremental crawl is run, SharePoint determines whether or not a document has changed and should therefore be included in the incremental crawl results. It does it by performing a hash of the document, if the hash is different between crawls, then so is the document and the document is readily; though, perhaps not immediately available to search results, but are available prior to any complete crawl being run successfully.

This post is a continuation on previous SharePoint Portal Server 2003 performace recommendations and details basic steps to improve the overall full-text search queries for large database tables. The steps detailed are most applicable to enterprise deployments and/or large databases with a large number of unique full-text index words. The steps detailed below should be applied to each back-end SQL server(s). This problem occurs frequently if the total size of all the catalog files exceeds 256 megabytes (MB).

I recently came across an issue with a customer that uses large files in WSS, notably, .CAD files; as a result these files were either - one, not indexed or two, indexing did not gather the required information from the file to provide useful search criteria. To remidy the issue MaxDownloadSize was increased to 64MB while leaving the MaxGrowFactor at 4, this will essentially permit the index filter to produce up to 256MB (64 x 4) of text from a given file, the default setting in SPS is 16MB MaxDownloadSize and 4 MaxGrowFactor, limiting the index filter to 64MB max.