Change "Classification" of Communication Site?

Silver Contributor

How/where can we change the "Classification" of a Communication Site after it is created?

8 Replies
Where/How are you setting it in the first place?

I would like to know as well.   I just came across this scenario today and would like to know where this information is stored.

 

How to reproduce:

1. Configure classification taxonomy for Unified Groups ($setting["ClassificationList"] = "LBI,MBI,HBI")

2. Configure a default classification ($setting["DefaultClassification"] = "MBI")

3. Go to SharePoint launcher -> Create site -> Communication site

4. Specify site classification and click "Finish"

 

Communication sites are not a part of an O365 Group/ Unified Group, so there isn't a "classification" attribute to get/set from a Unified Group object.  I do not see a classification attribute in the Get-SPOSite object or in the Graph API.  Help to point out where this is stored would be great.

From my understanding this is not currently a supported use case but one that perhaps @Mark Kashman or @Christopher Fiessinger might comment upon.
From my understanding this is not currently a supported use case but one that perhaps @Mark Kashman might comment upon.

havent seen a set-pnpproperty command yet. get-pnpproperty will retreive the current setting.

 

Out of the box classification on modern sites : pnp video here https://www.youtube.com/watch?v=E-8Z2ggHcS0

i have followed this video and now have my custom classifications showing in the dropdown on the site creation dialogue for both team and comms sites.

Thanks! That was very useful. So it would involve the following to get this:

Connect-PnPOnline -url <urlto site>
$site = Get-PnPSite
Get-PnPProperty -clientobject $site -property classification

 

The use case for this is this:

 

Let's say you have a policy to enforce objects with Classification == HBI must not have guest access enabled ( I know bad example since guest access is not enabled by default...:). So you would have a Powershell script that would run on a scheduled basis to discover and enforce all modern team sites and communication sites defined as HBI do not allow guest access.

 

Then let's say out of unplanned foresight... What if we need to change the classification taxonomy in the future (ie. redefined and split HBI into both HBI and Top Secret)? And then define additional policies for both? We would re-evaluate all existing sites that have been assigned HBI and decide on if it should be changed to "Top Secret".

 

Once each site is re-defined, we would need to script and re-classify both the O365 Groups and communication sites at this point. While you can do so at the O365 Group level (which triggers a function to re-classify the modern team site eventually), there is currently no mechanism that I know of today to set the classification for a communication site once it has been set initially at site creation.

 

Also, would be nice to expose the classification property in the SPOSite or PnPTenantSite object. Doing a Connect-PnPOnline to get context for each site would be a rather resource-intensive operation. :)

this GitHub issue may be of interest. https://github.com/SharePoint/sp-dev-docs/issues/859

they also have used the group (I think that is what the exhange stuff is) as a workaround for team sites but as you say its no good for comms sites. Looks like the edit problem is an oversight and hopefully Vesa will pursue this one.

 

classification is available on the site object in CSOM and also on the pageContext in Typescript for SPFx  so we can use it to drive extensions which is good.

 

this.context.pageContext.site.classification

 

//csom testing site class property is available in Core v19

ctx.Load(spsite, s => s.Classification);

ctx.ExecuteQuery();

 

hopefully the update route will be tidied up so that PnP Core can handle the edits transparently in future.

update issues being addressed in PnP Core see SIG Nov 2nd video.
Comms site edits now all good from Site object. Have tried this myself and is fine.
Modern team sites have this little problem that a value is attached to both the site and the backing group. The group value overrides. To change the group means some messing about in Graph. Core is being extended to encapsulate this. Hopefully next release.