New Setting for the Site Property Bag
A relatively low-key but important change for a new tenant-wide setting was recently introduced to allow updating of a site’s property bag without having to enable/disable site scripts, which has been a requirement up until now. Microsoft’s Message Center post: MC714186 describes this change.
Background on the Site Property Bag
Setting a property at a SharePoint site level is not new and in fact, Microsoft sets many built-in site properties every time a SharePoint site is provisioned. There are practical use cases for wanting to add your own custom site properties anytime there is a requirement to include and/or exclude sites based on a property of the site. For example, an organization may want to search for sites by department. To do this, a department property could be added to each site as it is provisioned allowing, for example, to find all Finance sites.
Site properties are represented as a dictionary of key/value pairs in the site’s property bag. Following on with our Finance site example, to set a department property on every site, you would simply add a custom property with a key of SiteDepartment and a value of Finance. After ensuring the SiteDepartment property was indexed by SharePoint, the department values would be added to the SharePoint search index.
Third-party provisioning solutions for SharePoint (and Teams) use custom site properties all the time to provide custom behavior based on these properties. With no user interface to work with site properties, the only option is to use script or code to add, update, and remove them.
From a Purview perspective, site properties are used to build SharePoint adaptive scopes, an E5 feature previously blogged about here. In short, SharePoint adaptive scopes can be used to automatically apply retention policies and retention labels to all SharePoint sites included in the adaptive scope.
The Odd Coupling of Site Scripts and Site Properties
One peculiar behavior of adding/updating/removing a custom property in a site’s property bag is its dependency on-site scripts being enabled for the site. Understandably, Microsoft disables site scripts by default due to the security risks it introduces which can include malicious script, no audit trail for what script was inserted, where the script was inserted, and who inserted the script.
If required, SharePoint administrators could allow site scripts at a site level using either PowerShell or through the SharePoint Admin Center UI under the Custom script setting; however, it came with the security risks noted above. To mitigate the risk of this setting being left at Allowed, Microsoft would automatically revert the setting to Blocked after 24 hours.
The Old Way of Updating the Site Property Bag
With site scripts disabled, there was some housekeeping to take care of in your script when working with the site property bag. This was simple enough to do by setting the DenyAddAndCustomizePages site setting to false before working with the site property bag and, for best practice, making sure it was set back to true when complete. There was also a critical -Indexed parameter on the Set-PnPPropertyBagValue cmdlet to ensure the SharePoint search index would be updated with the property values. Without this setting, you would not be able to query on those properties even if they were set.
At the same time as SharePoint adaptive scopes were introduced in 2020, a helpful PnP PowerShell cmdlet, Set-PnPAdaptiveScopeProperty, was introduced to take care of this housekeeping for you. This cmdlet can be used to update site properties for any reason, not just for adaptive scopes. It encapsulates setting the DenyAddAndCustomizePages site setting to false, setting the key/value pair, ensuring the index parameter was included, and resetting the DenyAddAndCustomizePages site setting back to true all within the same cmdlet. This ensured the script builder needn’t remember to do it:
Import-Module PnP.PowerShell # Connect to SharePoint site $siteUrl = "https://contoso.sharepoint.com/sites/FinancialReporting" Connect-PnPOnline -Url $siteUrl -Interactive -ClientId <yourClientId> # Set the site property called Department to Finance Set-PnPAdaptiveScopeProperty -Key "Department" -Value "Finance" Disconnect-PnPOnline
Why the New Setting from Microsoft?
The new, long-named, tenant-wide setting, AllowWebPropertyBagUpdateWhenDenyAddAndCustomizePagesIsEnabled, decouples the site script setting from the ability to work with the site property bag eliminating the need to adjust the DenyAddAndCustomizePages setting at all. The new tenant setting can be updated using either of these methods as well as CSOM:
SharePoint Online Management shell:
Set-SPOTenant -AllowWebPropertyBagUpdateWhenDenyAddAndCustomizePagesIsEnabled $true
Link: Set-SPOTenant | (AllowWebPropertyBagUpdateWhenDenyAddAndCustomizePagesIsEnabled)
PnP PowerShell module:
Set-PnPTenant -AllowWebPropertyBagUpdateWhenDenyAddAndCustomizePagesIsEnabled $true
Link: Set-PnPTenant | (AllowWebPropertyBagUpdateWhenDenyAddAndCustomizePagesIsEnabled)
The New, Simpler Way of Updating the Site Property Bag
Once the AllowWebPropertyBagUpdateWhenDenyAddAndCustomizePagesIsEnabled parameter is set to true, you can work with site properties without having to adjust the DenyAddAndCustomizePages setting. Below is an example using PnP PowerShell:
Connect-PnPOnline -Url $siteUrl -Interactive -ClientId <clientId> # Set the site property called Department to Finance Set-PnPPropertyBagValue -Key "Department" -Value "Finance" -Indexed Disconnect-PnPOnline
If the AllowWebPropertyBagUpdateWhenDenyAddAndCustomizePagesIsEnabled parameter is set to false, I recommend continuing to use the Set-PnPAdaptiveScopeProperty cmdlet since it will continue to take care of the housekeeping for you.
Moving Forward
Work with your tenant and SharePoint administrators to determine if enabling this tenant-wide setting is necessary, considering your current and future needs for updating custom site properties.
