Table of Contents
Delving Into SharePoint’s Custom Properties
I’ve used SharePoint since the initial release of SharePoint Portal Server 2001, but I would never regard myself as being a SharePoint expert. I am perfectly happy to perform site management using the SharePoint Online PowerShell module or the admin center, but admit that the finer points of the client-side object module (CSOM) and the Patterns and Practice (PnP) library often surpass the limits of my knowledge. Given that much of SharePoint Online usage is generated by the sites used by Microsoft 365 Groups and Teams, less need exists to get down and dirty with CSOM or PnP than appears to be the case for SharePoint Server.
The Site Property Bag
However, sometimes no other option exists but to interact with SharePoint using PnP, which brings me neatly to the subject of the site property bag. This is a feature allowing the assignment of custom values to sites. If you come from the Exchange world, it’s analogous to being able to set custom properties for mailboxes. And just like custom properties are often used in Exchange as filters to identify specific mailboxes, the site property bag can refine searches by marking sites with custom values.
Custom values written into the site property bag are simple name/value pairs. For instance, the name might be “Test” and the value “Tony.” The idea is that users can then search for sites by looking for those where “Tony” is present in the “Test” property. Being able to find sites using a filter is important for functionality like adaptive scopes for Microsoft 365 retention policies. Custom values end up as crawled properties in the SharePoint Online search schema. The crawled properties can be linked to refinable strings to become searchable, which is how the property bag values can be used in filters.
Updating Values in the Site Property Bag
The standard Set-SPOSite cmdlet in the SharePoint Online management module doesn’t update the property bag, but cmdlets from the PnP PowerShell module do. To begin, I downloaded and installed V1.8.0 from the PowerShell gallery. The developers issue frequent updates for the module, so it’s wise to make sure that you use the latest (non-preview) version.
Before attempting to update the property bag for a site, you must disable the site’s DenyAddAndCustomizePages setting. By default, SharePoint Online blocks custom scripts, and to update the property bag, we need to lift the restriction temporarily. To do this, run the Set-SPOSite cmdlet to set DenyAddAndCustomizePages to 0 (zero). Before proceeding, make sure that the value of DenyAddAndCustomizePages is Disabled (the default is Enabled).
$Site = "https://office365itpros.sharepoint.com/sites/BallyconneelyBuglers"
Set-SPOSite -Identity $Site -DenyAddAndCustomizePages 0
Get-SPOSite -Identity $Site | Select DenyAddAndCustomizePages
DenyAddAndCustomizePages
------------------------
Disabled
The updated setting is effective immediately. The next step is to connect to the site using the Connect-PnPOnline cmdlet. An account can connect to a site only if it has access to the site. In this instance, I used a global tenant administrator account.
Connect-PnPOnline -Url $Site -Credentials $O365Cred Set-PnPPropertyBagValue -Key "OrgPrivacy" -Value "Restricted" -Indexed Set-PnPPropertyBagValue : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Site might have NoScriptenabled, this prevents setting some property bag values. At line:1 char:1
You’d imagine that a global tenant administrator can update site properties. After all, we’ve just used the same account to update the site customization setting with the Set-SPOSite cmdlet. However, the PnP module imposes its own rules. Everything looked good, but the error surfaced each time I attempted to write a new value into the site property bag.
After some debugging, I discovered that it is possible to update the site property bag only if you connect with a site administrator account. After adding the global administrator account as a site administrator, the Set-PnpPropertyBagValue cmdlet ran without a problem. If we examine the contents of the site property bag with the Get-PnPPropertyBag cmdlet, the custom value is present.
Get-PnpPropertyBag Key Value --- ----- GroupId ff168380-8f71-4419-980c-7f1e8e6ea83a vti_sitemasterid e2ea95e2-b7be-484f-bb63-e2b0fd4b38b6 vti_categories Travel Expense\ Report Business Competition Goals/Objectives Ideas Miscellaneous Waiting VIP In... vti_createdassociategroups 3;4;5 vti_defaultlanguage en-us HomepageProvisioned 1 contenttypessynctimestampversion 1 vti_approvallevels Approved Rejected Pending\ Review taxonomyhiddenlist 73396654-2d02-47d9-a078-6f0ffe401097 vti_associategroups 5;4;3 profileschemaversion 6 GroupDocumentsListId 2825b7cc-43f3-4eef-b970-f9789082f70d disabledhelpcollections SiteNotebookGuid ddb569bc-70b8-4eae-8e02-cd221f11d5d2 GroupType Public contenttypesusagebackfillversion 3 vti_associatevisitorgroup 4 vti_extenderversion 16.0.0.21409 OrgPrivacy Restricted GroupAlias BallyconneelyBuglers LastGroupSitePrivacyUpdated 637612064800877337 vti_associateownergroup 3 enabledhelpcollections VGSEndUser ProvCorrelationId 9462025b-ebf9-468c-bbde-3729d938bdbf FollowLinkEnabled TRUE vti_associatemembergroup 5 GroupDocumentsUrl Shared Documents vti_indexedpropertykeys TwByAGcAUAByAGkAdgBhAGMAeQA=|
After writing the custom values into the site property bag, make sure that you replace the block on custom scripts for the site:
Set-SPOSite -Identity $Site -DenyAddAndCustomizePages 1
Get-SPOSite -Identity $Site | Select DenyAddAndCustomizePages
DenyAddAndCustomizePages
------------------------
Enabled
Checking Custom Scripting Status for Sites
Some blogs say that the DenyAddAndCustomizePages setting reverts to the default setting after a period. I have not seen this happen, but this could be simply a case of not waiting long enough for a SharePoint Online background Some blogs report that the DenyAddAndCustomizePages setting reverts to the default setting after a period. I have not seen this happen, but this could be simply a case of not waiting long enough for a SharePoint Online background process to work. In any case, it’s best to be proactive and leave sites in the correct state. A quick check with PowerShell will reveal any sites which need to be updated and correct the situation. In this example, we check only for group-enabled sites:
$ScriptingSites = 0
[array]$Sites = Get-SpoSite -Limit All -Template Group#0 | Sort Url
ForEach ($Site in $Sites) {
If ($Site.DenyAddAndCustomizePages -ne "Enabled") {
$ScriptingSites++
Write-Host ("Site {0} has scripting enabled, so now disabling scripting..." -f $Site.Url)
Set-SPOSite -Identity $Site.Url -DenyAddAndCustomizePages 1 }
}
If ($ScriptingSites -gt 0) { Write-Host ("{0} sites found with scripting enabled - now disabled." -f $ScriptingSites) }
If you’ve added a tenant administrator account as a site administrator to update the property bag, make sure that you remove the account afterwards. It’s not good to allow access to site contents to tenant administrator accounts unless this is intended.
Moving Forward
As it turns out, updating SharePoint Online site property bags isn’t difficult. That is, if you satisfy all the requirements. In this case, making sure that you use a site administrator account is the important point. It’s something that I didn’t see covered in any of the blogs which describe how to update the property bag (I’m sure this is documented somewhere). Now that I know how to assign custom values to SharePoint sites, the road is clear to use these properties in adaptive scopes.
Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.
Hello, thank you for your article. You mentioned the following,
> I discovered that it is possible to update the site property bag only if you connect with a site administrator account
Could you please explain how did you accomplish this?
I signed in with an account that was one of the site owners.