SOLVED

Remove a Sharepoint Site on Preservation Hold

Iron Contributor

We use Preservation Policies to meet compliance needs for our Sharepoint Online Sites and our user Onedrives. There is a site in particular with a subsite that I'd like to remove, but I can't due to the hold. I temporarily removed the site from it's corresponding Preservation Policy, and then attempted to remove the subsite. However, I was still greeted with the message "This site is on hold for eDiscovery" which prevents deletion.

 

What is the recommended way to remove this subsite?

 

P.S. We are not using "locked" Preservation Policies. 

13 Replies

It does take some time, did you check the DistributionStatus of the policy?

Looking deeper, it appears that the site will not actually remove from the policy. I have tried removing via the Admin Center and PowerShell, and each change results in a redistribution of the policy, but does not remove the site. Another bug?

It does look like a bug, let me try to repro...

Seems to be working fine for me:

 

[16:02:13][O365]# Get-CRetentionCompliancePolicy "test spo" | fl SharePointLocation

SharePointLocation : {Pesho}

[16:03:50][O365]# Get-CRetentionCompliancePolicy "test spo" | Set-CRetentionCompliancePolicy -RemoveSharePointLocation "https://xxxx-my.sharepoint.com/personal/pesho_xxx_xxx"

[16:03:58][O365]# Get-CRetentionCompliancePolicy "test spo" | fl SharePointLocation

SharePointLocation : {}

And I can confirm that the same shows after the distribution completed.

 

 

P.S. clearing out the last site should enable preservation for *all* sites instead if I remember correctly, but for the sake of testing this I guess it's good enough. Still, if you have a single site left to remove in your case, you might want to add another one first.

I'm not seeing the same result at all. After running Set-CRetentionCompliancePolicy -RemoveSharepointLocation, I can see that the desired site is still in the collection.

 

Our policies in general contain 100 sites, as this is the maximum allowed per policy. Once we reach that upper limit, a new policy is created and new personal sites are added to this. I am only attempting to remove one site from a policy that contains 100 sites, and it simply won't remove and no errors are returned.

 

I've put in a service request to see if this is a bug in our infrastructure. Thanks!

UPDATE

Running the same command a second time today resulted in a warning, but still no result:

 

PS C:\> $policy = Get-CCRetentionCompliancePolicy -Identity 'onedrive_34'

PS C:\> $policy.SharePointLocation.count
100

PS C:\> $UserUrl = Get-O365OnedriveUrl -LoginName user@domain.com

PS C:\> $policy | Set-CCRetentionCompliancePolicy -RemoveSharePointLocation $UserUrl
WARNING: The command completed successfully but no settings of 'FFO.extest.microsoft.com/Microsoft Exchange Hosted
Organizations/tenant.onmicrosoft.com/Configuration/Onedrive_34' have been modified.

PS C:\> $policy = Get-CCRetentionCompliancePolicy -Identity 'onedrive_34'

PS C:\> $policy.status

PS C:\> $policy.SharePointLocation.count
100

PS C:\> $policy.SharePointLocation | where name -eq $UserUrl

DisplayName       : user
Name              : https://tenant-my.sharepoint.com/personal/user_domain_com
ImmutableIdentity : 1;Web;https://tenant-my.sharepoint.com/personal/user_domain_com;user;fbe5e784-bf5b-456a-a7ce-4173d8295
                    6e7;456330f1-4db7-4567-a55e-ac744ae8fe77;
Type              : IndividualResource
Workload          : SharePoint
SchemaVersion     : 2

You can see that the Set-CCRetentionCompliancePolicy command returned that no settings were changed, but the URL in question still exists in the SharepointLocation collection and the collection still contains 100 sites. Weird!

 

Note that the command Get-O365OnedriveUrl is simply a custom function that takes in an Office 365 username and calculates the personal site URL string.

The warning should be normal if the url is simply not present in the list anymore... maybe some sort of replication issue on the backend? Definitely check what support has to say about it.

I reproduced the issue over a screenshare with support, and they confirmed it's not working as expected. I'll let you know if they find a real bug, or if it's something else.

best response confirmed by Matt McNabb (Iron Contributor)
Solution

UPDATE

 

I was able to fix the problem by creating a new policy with the same sharepoint sites of the original policy, and then removing the original policy. This seems to indicate that the problem lie with the policy itself. 

 

It's very possible that I still have other policies that would be affected by this problem, but with a relatively easy fix I'm not too worried about it. If I run in to the situation again I'll be able to deal with it.

 

Also, a big shout out to the Compliance and Security support team, who so far have been great to deal with. Thanks!

Hi,

 

I have enabled preservation policy for all the users in one drive, Now i need to remove the preservation policy for one user. How i can identify the user in which retention policy and how i will remove that

 

More over i noticed preservation policies will occupy the storage quota on the one drive whether it is true


@Sankarasubramanian Parameswaran wrote:

Hi,

 

I have enabled preservation policy for all the users in one drive, Now i need to remove the preservation policy for one user. How i can identify the user in which retention policy and how i will remove that

 

More over i noticed preservation policies will occupy the storage quota on the one drive whether it is true


Are you able to use PowerShell for this task? If you are, finding and removing a site from a preservation policy isn't too hard.

yes i can do it. i found some command to remove the user from retention policy but still the same error message. user unable to delete the document

@Sankarasubramanian Parameswaran Just went to the same issue. You need to delete the Office 365 groups in two places. If you delete online in the Admin Center->Groups, you still need to go inside Portal Azure and permanent delete the Groups there. Portal Azure ->Azure  Active Directory -> Groups -> Deleted Groups -> Send them to SPACE :)

 

You give a day or two and the sites will be deleted. :)

 

This whole issue has nothing to do with ediscovery policies.. crazy!

1 best response

Accepted Solutions
best response confirmed by Matt McNabb (Iron Contributor)
Solution

UPDATE

 

I was able to fix the problem by creating a new policy with the same sharepoint sites of the original policy, and then removing the original policy. This seems to indicate that the problem lie with the policy itself. 

 

It's very possible that I still have other policies that would be affected by this problem, but with a relatively easy fix I'm not too worried about it. If I run in to the situation again I'll be able to deal with it.

 

Also, a big shout out to the Compliance and Security support team, who so far have been great to deal with. Thanks!

View solution in original post