How to exclude content from Microsoft 365 Search


Recently I was asked by a customer using SharePoint to host all their insurance claim content how they could exclude the content from showing up in searches from their Microsoft 365 Intranet.

Search has evolved in Microsoft 365 with two engines, Microsoft 365 Search and SharePoint Search. Had it been configuring SharePoint search I would have no problem showing them how to do it.

With Microsoft 365 Search, I was sure there was a way as I remember hearing something about search configuration in the back of my mind but was not sure.

The issue was more important because they had switched off search within the site collection. So that the content did not display but this had some unexpected consequences.

Including, they could no longer find content associated with their claims application. List searching and filtering did not work anymore. This made administering the application difficult which had millions of associated files. Finally, if they later wanted to improve performance by using search to improve the experience for their teams then this would no longer be possible.

A solution was needed!

Fortunately, Microsoft’s effort in improving the Microsoft 365 Search configuration experience has made it possible to do what we want to do.

Let’s provide a bit of background.


So how can this be achieved?

Well, firstly, let us explain what needs to be configured. When you do a search from any of the Microsoft 365 search boxes for example in SharePoint or Teams you get a set of results as shown below.

Example Microsoft 365 Search from SharePoint Online

You can see a summary of search results but if you click on “Show more results” then this expands to a dedicated search results page. This results page allows you to refine the search across different categories (called search verticals) to make it easier to find the right resource. By default, these search verticals include things like filtering to just files, people, news, and images.

Example of a search result with search verticals.

We bring up the search verticals as this is how we will config Microsoft 365 Search to exclude content. We will also need to configure each of the search verticals as well to ensure that one of them does not bring unexpected content back.

Microsoft Search uses Keyword Query Language or KQL and it is possible to configure this to restrict the search results to a particular result set. More information on KQL can be found at


Now, with Microsoft 365 Search it is possible to configure the search and these search verticals to exclude content. So, how do we do this?

Firstly, the user to do this will need to have one of the following roles:

  • Global Admin
  • Search Administrator

Firstly, let’s say that the site content that we want to exclude is found on a site with this URL,

To do this do the following:

  • Click Show All
  • Click Settings->Search and Intelligence
  • Choose Customizations and then Verticals
  • Select the All Vertical and choose Edit
  • Click on Query and then Edit
  • Keep the name of the vertical and, click Next
  • Paste the following KQL as shown below.
  • Click Next

NOT (path:

Configure the Query for the Search Vertical
  • At the Filters click Next
  • Review the vertical settings, and click “Update Vertical”
  • Wait a few seconds
  • Click Done and go back to the vertical settings screen.

With this vertical completed now repeat the process for the other search verticals.

How long does this take to apply to Microsoft 365 Search?

In my experience, it can take up to 3-4 hours for the changes to take place.


So hopefully armed with this knowledge you can now configure your Microsoft 365 Search so that it excludes content without disabling search and making life harder for you and your admin teams when they are working with sensitive local content.

Connecting SharePoint Online to On-Premise Databases with SharePoint Framework (SPFx)


Recently we seem to be getting involved in projects after they have gone awry. One of our partners reached out asking for help with an issue they had whilst migrating a SharePoint 2010 environment to SharePoint Online.

The problem was that the customer made extensive use of Dataview Webparts with their SharePoint 2010 environment. These web parts displayed important information used by the business. The Dataview Webparts connected directly to a SQL server hosted within the customer database.

Of course when the web parts were migrated into the cloud, they did not work as they were unable to connect to the SQL Server. This ended up stopping the migration until a solution was found.

The customer did not want to move the data into the cloud due to several reasons but the most important one being all of the other systems dependent on it.

Several options were discussed which will be discussed in the next session.

The approach

So several options were looked at, and as moving the database was quickly ruled out, we came up with these two:

  • Build a solution with PowerApps and use the On-Premise data gateway.
  • Build a solution with SharePoint Framework using a REST API use Azure Hybrid Connections

Whilst the PowerApps solution would take less time, the licensing cost of the PowerApps solution ended up ruling it out due to its total cost of ownership (TCO).

So, the SPFX solution was chosen. The architecture was to use SPFX webparts which connected to a REST API hosted in Azure App Services. The clever part was using Azure App Service Hybrid Connections which allowed us to connect from Azure back into the customer network without the need to reconfigure complex firewalls.

To help visualise the solution, let’s take a look at the architecture.

We ended up having two Azure Hybrid Connection Services running. One for the active live environment and another for the disaster recovery environment.

The data being accessed was sensitive so the REST Api had to be secure. It was configured so that it was backed by Azure AD using an Azure AD Application, implemented with OAuth authentication using JWT Bearer tokens. The SPFX connected to the REST API and authenticates using Open Id Connect to ensure that only authenticated and authorised users can access the API. Further protection was provided by setting the API behind Azure API Management.


For the SharePoint Framework web parts to be able to authenticate with the REST API there are a couple of steps that need to be performed:

  • Configure the SharePoint Framework solution to request permission to access the REST API
  • Authorise the request made by SharePoint Framework to access the REST API.

To configure the SharePoint Framework solution take a look at this Microsoft post which provides a good guide (see section Configure the API Permission Requests).

The second part is performed by going into the SharePoint Admin centre and approving the request. Now the point to make is that the user accepting the request needs to be a SharePoint Administrator and also grant admin consent to Azure AD Applications. Basically a Global Admin has this role, so we worked with the IT team to ensure a privileged user did the authorisation. Be mindful of this when deploying to the customer as that will take some discussion and time to organise!

The screen to authorise SharePoint Framework solutions.

Another point to make here is that the name of the Azure AD Application configured in the SharePoint Framework needs to be map to the name of the Azure AD Application configured in Azure AD. This is configured as mentioned above in the SharePoint Framework solution. When I first looked at this I set the resource to be the resourceid for the Azure AD Application rather than the name of the application.

Hopefully mentioning this will mean you do not waste your time getting this right.

"webApiPermissionRequests": [
        "resource": "HROnline Api",
        "scope": "user_impersonation"

Azure Hybrid Connections

The Azure Hybrid Connection is setup in two places.

  • Azure App Service hosted in the cloud
  • Hybrid Connection service – running as a Windows server within the network.

The hybrid connection service establishes a connection to the Azure App Service through Azure Relay which is built on top of Service Bus.

Diagram of Hybrid Connection high-level flow

To setup the Hybrid Connection in Azure App Service you must be running at least the Basic Tier or above.

There are some limitations to the types of connection that the technology supports. The transport mechanism needs to be TCP based and does not support UCP. For this solution a .NET SQL Client was used which is supported and works really well.

For information on setting up the Azure Hybrid Connection see the following Microsoft article.


One of the areas that we wanted to ensure was the performance of the applicatoin. So we put together a POC was put together to prove the approach and also check performance. The performance has been very good and provided that the REST ApI is developed with some thought, it performed better than expected.

There was plenty of thought that went into the API. A few of the optimisations we made were

  • making sure that we had support for paging and limiting the number of records retrieved at one time.
  • Using Dapper and performing filtering at the SQL layer rather than pulling the data down and filtering in the API


This solution enables SharePoint Online solutions to access data hosted On-Premises and it does work really well. To be honest we were surprised how well the solution performed.

Most importantly, he partner and customer were really happy with the end result too.

I hope that people find this post useful, if there is an aspect that you would like more information on then leave a comment and I’ll see what I can do.