UPDATE – Fellow MVP Joanne Klein reminded me of the Retention Containers via twitter. These are used to wrap up expired groups and their content when a Retention Policy label is in play. It would appear that this is the behaviour that we’re seeing below in Classic Site collection. This actually makes a lot of sense, however I think the implementation is a bit of an issue from the User Experience point of view. 

For example, I can delete an entire site-collection without a warning, but individual sub-webs get blocked. I understand why that is due to the differences in how the deletion is handled, but the differences could be confusing to users (Though not many users will be deleting Site Collections). The problem comes while the Classic SharePoint admin site is still in use (So not a problem for much longer one hopes!) and a well meaning admin tries to restore the site collection for the confused user. I haven’t tested the new Admin site for this problem, but I’m guessing it’s been built to be aware of the Retention Container scenario as it handles Group connected Site Collections. I’ll test this further when I’m done travelling today.

Classic Site collection deletion issues with Office 365 Retention Labels

The evolution of governance in Office 365 has seen the creation of Office 365 labels, a policy based system that allows governance and retention to cross the system boundaries between SharePoint, Exchange and OneDrive. The idea of providing a centralised means of enforcing retention and deletion policies across the Office 365 ecosystem is very welcome, but unfortunately not without a few odd behaviours.

While working on a proof of concept with a client, I was working with a classic site collection and demonstrating some of the options that they had for managing retention. Although Information management policies are not Microsoft’s preferred way of managing retention in Office 365, it currently is the only way if you need to enforce automatic retention based off of a property on a document that isn’t the created or modified date.

All was working fine until I went to delete the site collection to re-roll the proof of concept site for further testing. To try and keep the clutter down to a minimum in the tenant, we were planning on reusing the same URL. This generally isn’t a problem so long as you delete the site collection and then remove it from the recycle bin. I deleted the site collection in the SharePoint Admin centre, then went to PowerShell and issued the Remove-SPODeletedSite cmdlet to purge it from the recycle bin.

Remove-SPODeletedSite : Unable to find the deleted site: etc….

Not what I expected at all, Issuing a Get-SPODeletedSite command, it returned nothing. Get-SPOSite however returned the site I expected to see. Browsing to the site however resulted in a 404 Not Found. Confused? I was.. Even more so when I tested the next morning and found that I could browse to the site once more!

In the end, I raised a call with Microsoft and we did various elements of testing with minimal success. In the end I went web by web deleting each one in turn until I got to one that triggered an error on deletion:-

I decided to do some testing in a controlled environment in my personal tenant, and sure enough we can recreate this scenario quite easily by trying to delete a site collection with a single document protected by an Office 365 Retention label.

The set-up that I’m using to test is as follows:-

We’ll now issue a Remove-SPOSite with the no-wait command against both sites.

Both commands come back to the prompt in a few seconds as expected. After a few minutes have passed, I issued a Get-SPODeletedSite to show the recyclebin according to PowerShell.

And if we try to browse both sites, we receive a nice 404 not Found error..

If we now go and take a look at the Recycle Bin in Central Admin:-

Both sites are clearly visible here…

But if I go back to PowerShell and issue a Get-SPOSite command, you can see that SharePoint clearly thinks that the site is live still.

So we’re now in the following state:

At this point, I can simply remove DeleteTestA with the Remove-SPODeletedSite cmdlet and then rebuild the Site Collection at the same URL without any issues. DeleteSiteB however is now in complete limbo. I can’t remove it from the recycle bin in PowerShell because it doesn’t seem to exist there, therefore I can’t create the new Site Collection at the same URL because SharePoint thinks that URL is in use.

In the client tenant, the site was restored by Microsoft in the backend and I was able to go into the site and remove the Office 365 Label that was blocking the deletion. In my test tenant, I decided to try and restore the DeleteTestB site collection from the SharePoint Admin recycle bin to see what would happen…. Oops.

I can now browse to the site and it looks like my site, but there’s no content in the document library?! If we return once more to PowerShell and this time try the Get-SPOSite cmdlet with the full URL….

So we now have two site collections at the same URL, but with different SiteIDs. This explains the empty Document Library in the restored site as there is no content in the Content Databases for that particular Site ID.

Wow we’re in a little bit of a pickle huh? Tell you what let’s delete the Site Collection again! That doesn’t take too long and soon enough we now have two sites in our Recycle Bin… And to top it all; off, we also have a site entry showing in the Get-SPOSite list too…

In summary:

As I said at the start, this scenario came about because of some proof of concept testing that we were doing for a client, but it’s very possible that you may be cleaning up your tenant, deleting old Site Collections and just one of them might have some Office 365 Label driven retention policies..

At the moment, I don’t have any PowerShell scripts that can identify labels that have been applied to Documents or Libraries. I’m reaching out to Microsoft and the PNP team to see if the relevant API calls exist yet or not and will also be raising this as a bug for the program team to take a look at. I’ll update this post once I know more.