I spend a fair amount of time on SharePoint.StackExchange.com and a very common question there is “How can I search for SharePoint Sites” the most common response, from those of us who like to help, is “Execute a query for ‘ContentClass=STS_Site OR ContentClass=STS_Web’ and you will get a result set of Site Collections (STS_Site) and Webs (STS_Web) that you have access to.” While this answer is technically correct, there is a larger subtext to this routine question. What I find most often is that the real question is “How do I create a searchable catalog of sites, with metadata, to which I have access?” This is where I find the most common response is terrible advice “Use the Property Bag!”. I SCREAM at my monitor “NOOOOOOO!!! Don’t use the property bag. I know you CAN, but it does not mean you SHOULD!” The problem, I find, is that there are many examples and posts on how to use the property bag as a “solution” to this often-asked question and nothing on what I consider the “right way” to answer this question.

The Right Question

What is the right answer? Well, let’s take a good look at the right question first, then you can determine if my solution is the right approach. Having spoken to my customers, students and colleagues here is the list of requirements I have developed over the years. Yes, years, because we have been “solving” this “problem” since SharePoint 2003. You’d think Microsoft would have come up with an answer for this by now, but nope, not for lack of trying, but no. OK, in no particular order the requirements are:

1. Supports Classification of the Site with metadata like:

• Site Title
• Site Description
• Related Department, Organization, Team, Etc.
• Site Logo
• Confidentiality Level
• Security Level
• Classification
• Site Manager (not the Owner, but the person in charge of the site…the contact)

2. Search Results have their own vertical in the Search Center
3. Search Results have a unique look that shows the information in #1
4. The classification data is easy to maintain, update, and change by the site manager (owner, editor, member, etc.)
5. Site catalog search security trimming. Here there are two camps:

• Site Results only appear for sites to which the user has access
• Site Results appear for all sites in the catalog including site they may not have access to

The Wrong Answer

What is the Property Bag? Well, every object in the SharePoint API has a Properties property. It is a hash table or table of key/value pairs where a developer can read and write custom values. There are a lot of properties on the SPWeb object used by SharePoint. In PowerShell, you can view these properties like this:

But the thing that makes this option so dangerously compelling is that there is an “interface” to add, update and delete these properties: SharePoint Designer!

In fact, there is even an option to add properties from the property bag into a special list that will make it available to the index!

$web.IndexedPropertyKeys.Add("MyCustomProperty")

So, what is the problem? Looking at these requirements the Property Bag begins to fail at #4 and cannot work for #5. Opening SharePoint Designer to perform a property bag update is not my idea of easy. Of course, developers have stepped up and created custom solutions for managing the property bag.

The Right Answer, The Supported Answer, The Out of the Box Answer

I think the main problem is that all of this noise about the property bag misses two HUGE points.

1. There is an out of the box option that works in all versions of SharePoint including SharePoint Online.
2. If you require a solution that is not security trimmed, the Property Bag approach does not work.

The right answer is to use a SharePoint list, I prefer to use a custom content type as well. Then I add the list to every site I want to classify and let the site manager handle the rest. I create a custom Display Template and the results work for my clients. If they need everyone to have access to the catalog, we just create the list separately where everyone has access and link to the site.

That’s It?

I know what some of you are thinking. “Wait? That’s it? A LIST?” I know, it’s boring, but it WORKS! It does not require a developer, though, if you have a little bit of skill with PowerShell it is super easy to maintain. If you are using a site provisioning workflow you can easily add the list to any site. Most importantly, it satisfies all of the requirements without any custom code.

So, there it is, my plea to stop using the Property Bag and my solution for how to solve this ever-present problem my way, which I think is the right way. To support this process, I am going to create a series of videos that go step by step through the process because this kind of Search Project has so many great lessons! Here is my commitment to you:

1. Foundation: Create Custom Content Type from Site Columns
2. Foundation: Create a Custom List with a Custom Content Type
3. Build the Solution: Managed Properties, Custom Vertical, and Result Sources
4. Build the Solution: Refiners and Display Templates
5. Build the Solution: Query Rules
6. Build the Solution: To Trim or Not to Trim that is the Security Question
7. Build the Solution: Using Automation to Manage the Solution