SharePoint Search 2013: Why are there so many Managed Properties?

Hi,

I recently wrote a posting about the new search schema in SharePoint 2013 on the SharePoint IT Pro blog. Afterwards I was asked why there are more than 600 managed properties available directly out of the box (view entire Managed Property list), and if this really, really is necessary.

Well, 600 is more than in SharePoint 2010 Search Server, and more than in Fast Search for SharePoint 2010, but not more than the sum of those two. So let's take a quick look at some of them.

There are several reasons for why there are more managed properties than before, the main reasons are: 

1) Backwards compatibility so that FS14 and SS14 based content farms can search towards a SP 2013 search farm. Right, if you have a setup today with multiple content farms and one search services farm (aka federated farm) you want to be able to upgrade the search services farm independently of the content farms. In order to accomplish this, the search farm needs to have the managed properties required by those content farms.

2) New SharePoint features depending on search, such as video search, content by search and cross-site publishing features. Each of these features typically could re-use many of the existing managed properties but also needed new ones.

3) New ranking and analytics features, capturing data into properties such as ViewsLast3DaysUniqueUsers. To provide improved relevance of the search results, more data about usage of the documents need to go into the search index. If more users open a document that indicates that the document is more valuable than another similar documents with fewer clicks, and we need to keep track of this.

4) The new multiple index schema mechanism with index schemas on tenant and site collection level (covered by the other blog post). To accomodate this without making things too expensive these additional schemas cannot create "expensive managed properties". However, they can reuse existing managed properties, and we ship with a number of default unused managed properties named RefinableString22 etc. There are 270 of these managed properties in total, if I managed to get the math right.

So a natural question is: Can you delete any managed properties without messing up your installation?

Well, yes you can, if you own an on-premises installation and you are central administrator you can do this from the search schema UI, or from PowerShell. Deleting managed properties based on categories 1 and 2 above are not recommended, so I will not mention any of those here. Category 3 is a key part of SharePoint 2013 and should also be left alone. However, the fourth category of properties is a different story. All of these can be deleted without affecting the system as it is out of the box (but then site collection admins can no longer use them of course). Removing them will not save any measurable space in the index (since all those structures are smart and do not occupy disk space nor RAM if they are empty), but they will make your schema management page look cleaner.

Hope this was somewhat informative, please feel free to rate this posting, give comments, clever remarks or contact me directly.

-Helge

PS - I am considering writing a posting about how the different managed properties attributes (queryable / searchable / sortable etc) maps into actual indexing structures. If this sounds interesting or if you have other ideas for related topics of interest, feel free to ping me