Using SharePoint PropertyBag in the Context of Search

Editor’s note: The following post was written by SharePoint MVP Nicki Borell

The Property Bag is a “store” within SharePoint which can be used to places information’s and metadata. Property Bag is a hierarchical structure starting at farm level and goes down up to list level.  Microsoft itself uses the Property Bag to store configuration settings and information’s. For details see that msdn article: Managing SharePoint Configuration

For common information’s about the Property Bag please refer that msdn sites:

The question is what benefit provides the Property Bag to us also in the context of search. In common we can use it to store variables or other metadata who belong to a site or list. Creating searchable properties in the property bag of a web, a site or a list allows us to search for them by the value of its property. Using that makes it easy to build search driven sites aggregating special subsides or list based on the value of such a searchable property. In case you work with custom website templates you can place a property in the Property Bag showing the type of your custom template. On the other side you can use search to say: ”Show me all sites where type is %whatever%

We have several options to work with the Property Bag. In fact we can use SharePoint Designer, PowerShell and of course custom code. In addition there is a codeplex project named SharePoint Property Bag Settings.  It is providing a farm solution to work with the Property Bag using the SharePoint UI. Poorly not all options give us the same potential.

Creating your own value in a Property Bag can be done with all options. But to create a property that is covered by search we have to respect some special things. For example creating a property in a Property Bag using PowerShell would work like this:

$WebUrl = "http:// %Server% /sites/ "

$web = Get-SPWeb $WebUrl

$web.Properties [ "MyNewProperty" ] = "MyValue1"

 

But to make the property covered by search we need to do the following steps:

$WebUrl = "http://%Server%/sites/ "

$web = Get-SPWeb $WebUrl

$web.AllProperties [ "MyNewProperty" ] = „MyValue1"

$web.IndexedPropertyKeys.Add ( "MyNewProperty" )

$web.Update ()

 

Doing this using custom code it would look like that:

SPWeb web = SPContext.Current.Web;

web.AllowUnsafeUpdates = true;

web.AllProperties[“MyNewProperty”] = "MyValue1";

web.IndexedPropertyKey.Add("MyNewProperty");

web.Update():

web.AllowUnsafeUpdates = false;

 

Poorly this cannot be done using CSOM. IndexedPropertyKeys are not part of the ClientObjectModel and also not available via REST. Thanks to my MVP colleague and company associate Thorsten Hans for supporting me with this question.

There is also no way to set this up using SharePoint Designer or the codeplex solution SharePoint Property Bag Settings. SharePoint Designer and the codeplex solution are helpful to see which properties already exist, to see which value they have or to change values.

This screenshot shows the Property Bag using SharePoint Designer. By clicking the button “Site Options” in the Ribbon, the shown dialog comes up. In the dialog you can see a custom property I created called “PowerShellProp”:

 

 

This screenshot shows the same information using the codeplex solution:

 

To get a list of properties from a Property Bag we can also use PowerShell.

$WebUrl = "http://%Server%/sites/ "

$WebUrl.Properties | Format-List

To get a list of all properties covered by the search we need to use that call:

$WebUrl = "http://%Server%/sites/ "

$WebUrl.IndexedPropertyKeys | Format-List

Before we can use the new property within the search we need to do a full crawl. After the full crawl we had a new Crawled Property named like our Property we created in the Property Bag in our search schema. To verify that the new crawled property exists we had to browse the search schema as described in respective msdn article: View crawled properties and managed properties

To use that property in search queries, search driven solutions or as a search refiner we need to map it to a Managed Property. Therefore we can use an already existing Managed Property or create a new one. How to do that mapping is described in following msdn article: map a crawled property to a managed property

After another full crawl the property can be used within search.

A hand on lab demo is shown in that video:

[View:https://youtu.be/DgjE64QPP6Y]

 

About the author

Nicki Borell (http://www.sharepointtalk.net/) is an evangelist & consultant in the Experts Inside team (www.expertsinside.com). He has worked for more than 13 years in Microsoft enterprise environments and also as a trainer and consultant for the SharePoint and SQL Server products. His expertise extends from technical consulting all the way to project management, with his core competencies covering KMU, enterprise environments and government data management. His special focus is on SharePoint Search Technologies. Nicki is Microsoft MVP for SharePoint, Microsoft Certified System Engineer (MCSE), Database Administrator (MCBA), IT Professional (MCITP) and Trainer (MCT). Follow him on Twitter.

About MVP Monday

 

The MVP Monday Series is created by Melissa Travers. In this series we work to provide readers with a guest post from an MVP every Monday. Melissa is a Community Program Manager, formerly known as MVP Lead, for Messaging and Collaboration (Exchange, Lync, Office 365 and SharePoint) and Microsoft Dynamics in the US. She began her career at Microsoft as an Exchange Support Engineer and has been working with the technical community in some capacity for almost a decade. In her spare time she enjoys going to the gym, shopping for handbags, watching period and fantasy dramas, and spending time with her children and miniature Dachshund. Melissa lives in North Carolina and works out of the Microsoft Charlotte office.