Anyone who has worked with SharePoint development in the golden age of server-side object model development (SOM) likely used the property bag for different requirements in their solutions.  With the onset of new development techniques and foundations, the property bag went by the wayside and wasn’t used as often (or at all) when creating solutions.  With the new adaptive scope feature in Microsoft Purview, property bag usage has made a resurgence as a necessary location to store values when assigning policies.  I will be covering these features in a future post, but for now, I’d like to set the foundation for these posts by discussing property bags and their usage.

What Is A Property Bag

Before digging into the “How To” of a property bag, let’s first cover what a property bag is.  The property bag has been a part of SharePoint for 20 years.  It’s an ad-hoc storage location within your site.  For on-premises SharePoint, it was often used to store configuration settings without using the web.config file of the SharePoint Web App.  Often developers would use the property bag to store important information for their apps to allow them to develop processes within the code that could act dynamically based on the value (without user intervention) without having to jump through hoops to access on-server configuration files or some other location.  A property bag would allow them to set the required configurations on the site itself without using locations that could be affected by users, such as SharePoint lists.

A property bag is essentially a hash table. It is made up of a key and a value.  Each key can have only one value.  A common use of a property back key\value pair was to signify the department a SharePoint site belonged to.  For example, the key could be OwnerDept and the value could be any department within your organization:

  • OwnerDept:HR
  • OwnerDept:Finance
  • OwnerDept:IT
  • etc

What are Property Bags Used for Today?

A property bag can still be used for custom development, but recently Microsoft made it a key component of Microsoft Purview features.  A property bag can now be used to to push department specific labels to the owning department’s sites using adaptive scopes, can be used to auto apply retention labels based on a value in the sites property bag, and can even be used in queries to kick off event-based retention.  I’ll cover these use cases in future posts.

How to Set a Property Bag Value on a Site

The most common method of applying a property bag value to a site is with PowerShell. An important item to take note of is that modern sites do not allow scripting which means setting the property bag will be blocked.  If you attempt to set the property bag value, you will get an error message similar to the following: “Site might have NoScript enabled, this prevents setting some property bag values.”

The Property Bag, What is it and How to Configure It - Failed Property Bag

Before running the the property bag PowerShell command, first update the site to allow for scripting.

Set-PnPSite -Identity "<SiteURL>" -NoScriptSite $false

To set a property bag value on your site connect to the site and run the following command:

Set-PnPPropertyBagValue -Key "OwnerDept" -Value "Finance" -Indexed

It is very important to use the -Indexed flag as part of the command if you wish to allow users or adminstrators to search for this value.  By default, a property bag is not indexed in search.  Running the above command sets the value within the site.  This can be checked using the following command:

Get-PnPPropertyBag -Key "OwnerDept"

The Property Bag, What is it and How to Configure It - InsertedIndexedPropertBagValue

In future posts I’ll demonstrate how to use this value with features of Microsoft Purview.

Thanks for reading!