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.
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:
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!
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.
I think the main problem is that all of this noise about the property bag misses two HUGE points.
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.
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:
Ready to start your next project with us? That’s great! Give us a call or send us an email and we will get back to you as soon as possible!