Having a proper life cycle process is important in every large implementation of SharePoint.

Site life cycle management is not the most exciting thing to implement but in my mind there’s still a special degree of satisfaction knowing that your house is in order. Not only the process for creating new sites but also the decommission and deletion of sites.

Over the years I have been involved in a number of projects where we have developed and implemented different custom decommissioning processes. Both in SharePoint Online and SharePoint on-prem. The benefit is that you can customize it in any way you (or the customer) want but there are still a few challenges.

The most natural thing to imagine is that you want to decommission, close and/or delete sites that aren’t being used anymore. Sites that no longer are active. The problem with this that its quite difficult to define what an active site is and then in code tell if a site is being used or not. With sync, different devices and other methods for accessing the information it’s quite difficult to tell the active sites from the inactive. You may also have apps, integrated third party applications and service accounts that trigger activity on sites that no longer are used by any actual users.

SharePoint Site Policies offer a different approach.

Most have probably heard about site policies in SharePoint. They have been around for quite some time. They work in a slightly different way where the policy and process operate on regular intervals, regardless of the activity on the site. The owner will then explicitly have to tell the system to postpone the deletion of the site for another period of time.

SharePoint Online Site Policy

The site policies in SharePoint Online are a little bit more limited compared to site polices in SharePoint on-prem due to the fact that the policy can’t initiate a custom workflow but they can still close and delete sites.

I like the approach that Microsoft has taken with the site policies for a number of reasons.

  • The owner has to actively choose to keep the site for another few months or years (defined in the policy). The owner gets a reminder of the site’s existence on a regular basis.
  • We don’t have to define and over time manage an algorithm for finding inactive sites.
  • It’s possible to centrally define several policies using the web interface and then implement different policies on different sites.
  • It’s possible to distribute the policies using the content type hub.

Last but not least, it’s out of box and I have heard that Microsoft is using these policies on their own sites, as part of their site life cycle management.

Applying a site policy using the web interface is quite simple well documented.

Applying a site policy in an SharePoint Online environment using PowerShell, using the client object model, is on the other hand very valuable if you need to apply a policy for a large number of sites at the same time.

Add-Type -AssemblyName "Microsoft.Office.Client.Policy, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
...
 
# Load all the current, available, policies.
$policyList = [Microsoft.SharePoint.Client.InformationPolicy.ProjectPolicy]::GetProjectPolicies($web.Context, $web)
$web.Context.Load($policyList)
$web.Context.ExecuteQuery()
 
# Find the policy to apply.
$policy = $policyList | ?{$_.Name -eq "My Policy"}
 
if ($policy) {
 
    # Apply the policy.
    [Microsoft.SharePoint.Client.InformationPolicy.ProjectPolicy]::ApplyProjectPolicy($web.Context, $web, $policy)
    $web.Update()
    $web.Context.ExecuteQuery()
    Write-host "Done"
}