Introducing Indexed property bag in SharePoint 2013 – a searchable collection of properties

Problem statement

You are tasked with building an automated site directory, most efficient, across site collections, and why not farm if you are there. (Piece of cake…so far). Add on top:

  • Enable support for additional properties
  • Try considering several lists too – with additional properties also
  • Super-fast, super performing
  • And I’m thinking – we should be able latter to use that as the source for our new global navigation menu

Not so easy anymore I hear you say – unless you jump right into programming your brains out. Or you could use Search – not bad as alternative, it does correspond to most of requirements, easily programmable and customizable, cross-site collections or even farms (if your environment is properly configured), but (yes, there is a “but”, otherwise this article would not need writing) – not a lot of information available other than Site/Web (aka sub-site) Title & Address and some content from the home page.

That is where one other great feature in SharePoint 2013 shines through, again pushing my favorite workload to day – Enterprise Search.

To recall in SharePoint 2007/2010 by making clever use of the STS_ContentClass one would be able to ask from the search index to return only Sites, or specific lists or library, or even list items. Let’s see examples (simply locate a Search center on your SharePoint installation and try these in search-box):

Remember the syntax is <Property Name><Property Operator><Property Value> more details on MSDN site @

So valid examples are:

  • contentClass : STS_Web – returns only instances of SPWeb (aka Sub-sites, of course )
  • contentClass : STS_Site – returns only instances of SPSite (only links to the Top-level sites)

Figure 1 Searching for sub-sites

A lot others are available on the same lines (list not exhaustive by any means, but simply search the web for “content class” next to SharePoint, in your favorite browser):

Searching for Search Term (append to
contentClass: )
People SPSPeople returns only People (provided you have user profile syncronization running)
Sites and Sub-sites (aka Webs) Return links to a top-level web or sub-sites
Site Collections STS_Site Only includes the actual Top-Level sites for any site collection. No sub-site information whatsoever.
Sub-Sites (aka Webs) STS_Web Only sub-sites (or webs) inside a site collection, not Top-Level sites
Lists or Libraries

Return links to views (no information about items inside) with description taken from parent list/library

Any list (generic) STS_List
Document Library STS_List_DocumentLibrary Form Templates & Data Connections libraries, etc. are also included
Picture Library STS_List_PictureLibrary
Events STS_List_Events Returns links to all Views in all Calendars
Tasks STS_List_Tasks Returns links to all Views in all Tasks list
Announcements STS_List_Announcements
Discussions STS_List_DiscussionBoard
Contacts STS_List_Contacts
Links STS_List_Links
Items in Lists

and/or Libraries

Return the actual items (or document links) in a particular list/library matching criteria, but not the List/Library where item resides.

Any list item (generic) STS_ListItem Pretty much every single item/document/page, etc.
Document Library Items STS_ListItem_DocumentLibrary Only actual links to Documents/Pages/Forms, etc.
Picture Library Items STS_ListItem_PictureLibrary Actual links to photos in a Picture library

…and the list goes on.

Figure 2 All Site Collections where keyword “project” is present

This give you an idea but still the problem is only partially solved. As you might have noticed from the screenshots (in the 2nd also an additional keyword has been used – “project” – highlighted afterwards in bold wherever found), very few details are automatically crawled and available for search (I mean who care really that a sub-site or web has a size of x kilobytes? – I know none of my users do).

Content class has its uses in many other places, to create repeatable & fine-tuned experience I would recommend go for search-scopes in use it to narrow down results as soon beyond what end- user is supposed to type in the search-box (notice in the screenshots that 2 more tabs are available – one only search a pre-defined Managed-Path for Projects, whereas the other only show Documents, and nothing else).

See more on Waldek’s blog example, but lots others are available out there around the same topic (

Enough history, let’s get back to our original intent. I was saying that a great new feature is available with the SharePoint 2013 called “Indexed Property Bag”. This builds up on the already existing Property bag (available via 2 collections – AllProperties and Properties – each with its own issues – for more details head out to

To sum up a list of properties are available by default with various objects in SharePoint (ever since 2007), such as Lists/Libraries, Sites & Sub-Sites, Web applications, etc. Most are set behind the scenes either by SharePoint (as you are performing various settings, such as changing the master page on a site) or by any custom code (or PowerShell scripts) that you are running on your SharePoint.

The new Indexed property bag comes with the added capability of being available for Indexing and Searching across. Practically this means that you could add as many information as you would to have visible as part of your search results and have those retrieved and finally exposed in the User interface. You are still limited to storing simple information (the only objects are actual Strings, other valid options being simple values such Integer, DateTime).

As a developer one has all the options available to configure these properties, either via the server-side API, client-side object model (available even via JavaScript) or PowerShell. For the end-user, not so much – there are several free developments on CodePlex, such as “SharePoint Property Bag Settings 2010” or the excellent “SharePoint Property Bag Management” which I would highly recommend to install for your everyday use. Also let us not forget the most excellent SharePoint Manager (available for all major SharePoint versions).

In PowerShell you would use something like this to store a new property (here to a SPWeb – a sub-site) – same could be achieved for any SPList and via C# code too.

$web = Get-SPWeb
$web.AllProperties[“Customer”] = “My Valued Customer”

How do we get to use it

  1. Make sure you populate all your custom properties at least for a single entity.
  2. Launch a full crawl (SP-CA > Your_Search_Service_App >Content Sources and select “Start a full crawl”)
  3. While still in SP-CA in the via the Administration page of the respective Search Service Application go to Search Schema (this has been changed from SharePoint 2010) and find the Crawled Properties. In order to be able to search across your custom properties, these must be indexed upfront and promoted to a Managed Property (just like with SharePoint 2010) and also marked as “Retrievable”.
  4. Once the operation is done for all your custom properties, run another full crawl.
  5. Try searching using a similar syntax as previously explained, but this time use your own property (name matching the one used to promote it as Managed property). This should return any results matching exactly your property based restriction. This also means that now you are ready to start tweaking your search results to include it in the display.

What has changed – quite a lot, as now by relying on Search capabilities, you can achieve everything and more, let’s summarize:

  • Custom attributes added to our site collection or sub-site (think here – link to additional images for a slider, information about owners, purpose, category, contact, etc.) – not only retrievable, but also searchable directly, like with any other attribute-based search (e.g. “Give me all sites in a specific Category”)
  • Should work not just for site & webs, but also other types of content – well the contentClass should deliver you pretty much everything
  • Super-fast & super performing – search is known to be the fastest – the only potential issues being here – freshness of data. This could be quite easily solved by adopting the “continuous crawl” feature
  • Can it be used later as potential “data-source” for a menu? Absolutely.
  • It will throw in another one – The new Content Search Web Part and HTML based rendering templates allows for great user experiences, which could also be linked directly to the type of content you have within your search results. So practically, you could design specific user experience Links, different than results for Events or Tasks. I’ll tackle that in a future post with ample examples.

Meanwhile, enjoy SharePoint!


One response to “Introducing Indexed property bag in SharePoint 2013 – a searchable collection of properties

  1. Thanks for a very good article! 🙂
    Have you tried displaying a these custom managed properties (based on a property in the property bag of a site) in the content search web part?
    I have trouble with this. I have followed the steps in your article. I can search on the new proparty in the search center, but when I try to show it in the content search web part (by selecting it under property mappings) it does not appear. :-/

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s