Removing a Retention Policy published to SharePoint in Office 365

Reading Time: 3 minutes

If a Retention policy is enabled and actively retaining content and you want to stop using it, how can you safely do this? I tested this out by setting up a Retention policy to retain content against a SharePoint site and made changes to some content in the site so the Preservation Hold library (PHL) was provisioned and storing content. 

[UPDATE April 19, 2020] I’m currently testing the timing of deleting SharePoint sites after a retention policy has been removed. Results are at the end of this post. As time permits, I will update this post with all of the scenarios.

Caution: this is a common requirement when you’re testing retention policies to ensure your cleaning up after testing. If you’re doing this in a production environment where you’re retaining production content, be aware of what this can do to content being retained.

Refer to Update MC182494: Enhancements to the Preservation Hold Library in your message center for details on how items in the PHL and the recycle bin will be handles to allow for grace periods before the content within it will be permanently deleted. This update is for Enhancements for SPO Preservation Library

Reference for retention policies in Office 365: Overview of retention policies


Option 1: Toggle the ‘On’ button to ‘Off’ for the Retention policy 

After doing this, the policy will initially go into an Off(Pending) status. I waited for a short period of time (< 15 minutes), and the status went to Off(Success). I ensured the Retention policy was no longer in effect by making a change to a document and verifying nothing was added to the PHL. The PHL’s content will remain on the site for a (by default) 30-day grace period after which the content will be deleted and will be placed in the second-stage recycle bin for 93 days

Note: the PHL will remain, only the content within it will be deleted.

Conversely, if you want to re-enable the Retention policy again and continue preserving the content, you can switch the status to ‘On’. Once the status is On(Success), the Retention policy will resume its work on all published locations and content will again be retained in the PHL. If you are within the 30-day grace period, the pre-existing PHL content will remain. 


Option 2: Delete the Retention policy without toggling the button to ‘Off’ first 

Rather than turning the policy ‘Off’, what happens if you delete the Retention policy while it’s still in an On(Success) status? When deleting the policy, it will pop open a confirmation window. If you select ‘yes’, the Retention policy will be deleted! After a few minutes (< 15 minutes in my case), the Retention policy is deleted and the PHL will no longer be updated. I also confirmed with PowerShell that the Retention policy was gone via the Get-RetentionCompliancePolicy cmdlet. 


What happens to the content on the site once the Retention policy is disabled/deleted? 

Assuming there are no other Retention policies in effect, the content on the site, including the PHL content will remain and the PHL will no longer be updated for a 30-day grace period. After this grace period, the PHL content will follow normal Recycle bin processing from that point. (going to the second-stage recycle bin)

What is the recommended way to remove a Retention policy? 

If you want to keep the Retention policy definition around, then deactivating it is a smart choice. If you don’t care, it doesn’t appear to make a difference if you disable the Retention policy prior to deleting it… eventually the policy is disabled/deleted and the PHL content will be cleaned up within the grace period defined. 

Can I delete a site after the Retention Policy has been turned off?

After 93 days… yes. The site will go in the Deleted sites section of the SharePoint Admin Center. It will remain there for 93 days (normal behavior for a deleted site)

After 30 days… (still testing – will update soon)

After Retention Policy is turned off… (still testing – will update soon)

 

Thanks for reading.

-JCK


Credit: Photo by Fernando Arcos from Pexels

7 comments

  1. You said you can change the 30 days of grace period by PowerShell

    I’m wondering if you know the script for that

      1. Hi Urs, I don’t know off the top of my head. I’ll update the post when I find that out.
        -JCK

  2. Hi Joanne, the behaviour you described whereby the PHL is not updated with new items after changing the Status of the retention policy to off is unfortunately not what we are witnessing. After setting the policy status to Off, waiting 15 mins and being presented as status equal to Off (Success), new documents created and deleted under SharePoint sites governed by this policy continued to be added to the PHL.

    This behaviour aligns with the MC182494 notice “Updated Feature: Enhancements to the Preservation Hold Library” published 18th June 2019 outlining the new 30 day grace protection. It states “During the grace period, any deleted item will continue to be preserved in the preservation library….”.

    In addition we also still cannot delete unwanted a Subsites even when set to Off. The message is the same as if the policy was on/active. This makes sense as it would be still trying to send it to the PHL.

    Best regards, Leigh.

    1. Hi Leigh,
      Thanks for your response! I’ll update the post with the clarification on the MC notification. I was trying to refer to it by my ’30-day grace period’ statements, but my wording could be clearer.

      Note: when I tested this, I’m pretty sure changed content was not going into the PHL – perhaps I never tested deleted content… I’ll have to test again.

      Please clarify – are you saying you cannot delete the subsites even after 15 minutes, 1 day, > 30 days, > 93 days (since items will now flow thru the second-stage recycle bin)? Although I don’t know if there’s a relationship to those durations and when you are allowed to delete it) How long after you’ve turned off the policy are you trying to delete the subsites? I’ve never tested against subsites, only site collections and I’ve never fully tested when you are able to delete the site that previously had a retention policy published to it.

      I’ll retest too (but only with site collections because that’s all I work with)… and update the post with findings/corrections. 🙂
      -JCK

  3. Hi Joanne,

    apologies for the delay. Was waiting for a reasonable period before reporting back. It’s been 21 days and I still cannot delete the subsite. Message is still “Sorry, something went wrong. This site cannot be deleted because it is included in an eDiscovery hold or retention policy”. The issue with waiting for the 30 days to expire is that vast quantities of deleted documents held behind the scenes in the Preservation Hold Library for future eDiscovery will also then be lost as they are well beyond standard recycle bin retention time frames. So we have no option but to re-enable the policy and live with these unwanted SharePoint web objects.

    I note you mentioned you only work with site collections (the new modern way), however when using 365 Group backed teams sites including MS Teams provisioned sites, nothing stops Owners from creating subsites as they are site collection admins. Subsite creation is still enabled out of the box. People will naturally therefore craft these structures unless prevented actively, even if they are just exploring their options or traditionally trained in SharePoint. Undoing these actions will be necessary unless you crack open SharePoint specific permission levels and customize in order to remove SCA from Owners and assign a custom permission level (role) with Site Permissions like ‘create subsites’ removed, going against modern O365 group permission model.

    This is what we have done for MS Teams provisioned SP site collections. Owners are no longer SCAs however they still have permissions to manage and add Channels via MS Teams thus preserving the basic MS Teams management functions. Powershell is used for applying this adjustment.

    In the meantime, for the example which existed prior to above controls, we’ve renamed the subsite to include [DELETE] prefix to make it obvious that the subsite should be avoided.

    Many thanks for your article and subsequent testing.

    Best regards, Leigh.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.