3 Things You Should Know About Site Policies for Life Cycle Management in SharePoint Online

We need to make it as easy and simple as possible for our users to utilize SharePoint and the other apps in Office 365. We do that through training, e-learnings, guidelines and by making it easy to create new groups, video channels or SharePoint sites. Preferably lowering the threshold in a way that the users can create these groups or sites themselves, in a matter of seconds.

Naturally this also require that we implement a life cycle management process for cleaning up and removing old and obsolete information and sites. However, this is unfortunately a field where Office 365 is falling behind at the moment. As easy as it is creating new groups or sites, it is just as hard for a service owner or a consultant to clean up and maintain a good life cycle process.

I have struggled quite a bit with the built in Site Policies in SharePoint to form a decent life cycle process for our sites in SharePoint Online. It has not been easy but it’s still the only tool offered by the SharePoint Online platform unless we want to build something custom or purchase a third party product.

I have come across three things that I think are missing in the documentation and everyone who plan to implement the Site Policies for managing a life cycle process in SharePoint Online should know.

1. The site policy will not remove the site collection

Applying a site policy on a top level site (root web) in a site collection in SharePoint Online in Office 365 is a bit special. If I delete the top level site using the web interface I also remove the site collection. The site collection and it’s top level site can then be restored from the recycle bin in the SharePoint Admin portal.

However, there’s a bug in Office 365 and SharePoint Online that emerge when a top level site is deleted using a site policy. The top level site (root web) is deleted but bits and pieces of the site collection remain.

When the top level site is deleted but the site collection remain we end up with an orphan site collection. The orphan site collection prevent us from restoring the deleted top level site. The remaining and empty site collection also reserve the url so we can’t create a new site collection using the same url.

It’s not possible to remove this orphan site collection using the SharePoint Admin portal or PowerShell. The only way to remove the orphan site collection is to contact Microsoft so they can run a script to completely remove the whole site collection. We as SharePoint global admins cannot run this script ourselves, it needs to be executed by Microsoft.

Not until it has been completely removed by Microsoft can we go ahead and restore the site again or create a new site collection with the same url.

The orphan site collections will appear in the SharePoint Admin portal but will generate an error when trying to review or update any of the properties.

There is no site in the current site subscription matching the HiddenSiteSelection control's value.


2. Re-publish the policy via the hub. You need to reapply the policy

We can use the content type hub to publish a site policy to all the site collections in our tenant.

We can also change the policy and re-publish it using the hub to distribute the changes to all our site collections.

Publishing a new version of the policy will however not update the applied policy on a site. We need to reapply the same policy again on a site in order to apply the new settings in the updated policy. So we can either accept that the new policy settings only are applied on new sites or use PowerShell or similar to loop the sites and apply the same policy again on all the existing sites.

The web interface is also behaving a bit strange. It’s not possible to reapply the policy again using the web interface without first removing the policy and then applying it again. The policy will not be re-applied when the name of the selected policy is the same as the currently applied policy.

3. Postpone the deletion will not postpone the site closure

One of the ideas with the site policy delete action is that site collection administrators can postpone the deletion. So we can make sure the site owner once a year explicitly need to tell the system to keep the site for another year or so. Like a review.

A policy can be setup to either delete the site collection right away (after a few reminder e-mails) or to close it first, before the site is deleted.

It’s tempting to setup the policy to first close the site, make it read-only for a few more months before deleting the site. This would be my preferred approach. Making sure all the site members and owners recognize that the site is about to be deleted.

It easy to think that postponing the deletion also postpone the closing of the site. That postponing the deletion will cause the process to start over, the site to remain open and then closing it again a few month before the site hit the new deletion date.

However, postponing the deletion doesn’t postpone the site closure. The site will be closed on the given date no matter if the deletion has been postponed or not. To make matters worse, it’s only the site collection administrator who can open the site again. This may very well prevent the members from adding new or updating contents for quite some time, especially if you organize the information using a lot of sub sites with individual policies.



Life cycle management is important!

Why? Not so much for the storage cost but rather for the sake of keeping our house in order and make sure all the information stored in our tenant have an appointed owner who takes responsibilities for it. Try to move towards closing old sites, groups or video channels. Identify the really important outcome of a project or a team effort, put it in a lessons learned repository, an archive or some other repository (possibly with a different owner) and delete the rest.

Having a lot of sites or groups, possibly with owners who have left the company doesn’t add any value according to me, not if we have a good process or a repository for storing and managing the valuable findings and outcome over time. A lot of clutter left behind may instead cause a lot of confusion and uncertainty.

I’m sure the search engines will become even better over time, AI and other features will also help us find the information that is most relevant for us but I still think it will be difficult to separate the clutter from the truly valuable information over time if we don’t try to keep our house in order and have the guts to remove information we don’t need.

Site Polices are not as good as I may wish they would be. Nevertheless, I like the idea that a site owner has to make a choice to keep the site for another year or so in contrary to many third party or custom solutions that try to figure out (and often failing) which sites are old and obsolete.

Leave a Reply