Removing Orphaned Sites: PowerShell Replacement for stsadm -o deletesite

  • Article

When running Test-SPContentDatabase as part of a SharePoint upgrade you may receive the following message:

Database contains a site (Id = [GUID], Uri [/]) whose url is already used by a different site, in database (Id = [GUID], name = [WSS_Content]), in the same web application. consider deleting one of the sites which have conflicting urls.

With site orphans you typically have a few options, including:

  1. Test and mount the content database to a different web application. This is often the case if you have multiple web applications in the source farm, each with a root site collection.
  2. Rename the site collection in the source farm so that the URL doesn't conflict, and both can coexist in the new SharePoint farm.
  3. Delete one of the site collections from the source farm before attempting a database attach upgrade to the new SharePoint farm.  This can often be accomplished using Remove-SPSite. However, what do you do if the site to be deleted is also orphaned in the source farm and Remove-SPSite fails?

Deleting Orphaned Site Collections

In the past we would use STSADM -o deletesite to force remove the orphaned site from the content database. While STSADM is still an option, even in SharePoint 2016, I prefer to use PowerShell, it fits better into my other processes and is easier to log and document. The PowerShell solution is to use the SPContentDatabase.ForceDeleteSite() method,  shown here:

 

# Note: The ForceDeleteSite method, with the parameters shown here, 
# bypasses the site collection recycle bin. 

# After running this, the only way to restore the site collection is to
# restore the content database from a previous backup

Add-PSSnapin Microsoft.SharePoint.Powershell

$contentDatabaseContainingOrphan = "WSS_Content_DB01"
$oprhanedSiteID = "75173058-dbb0-49b2-aaf9-f3f3bad1cd8c"

$contentDatabase = Get-SPContentDatabase -Identity $contentDatabaseContainingOrphan
$contentDatabase.ForceDeleteSite($oprhanedSiteID, $false, $false)

As noted in the comments this will permanently remove the site collection from the content database without asking for confirmation. Ensure that you have a recent database backup before attempting to run this.

For more information on resolving other Test-SPContentDatabase findings please see:

Post Upgrade Cleanup – Missing Server Side Dependencies https://blogs.technet.microsoft.com/dawiese/2017/05/09/post-upgrade-cleanup-missing-server-side-dependencies/

Test-SPContentDatabase False Positive for Classic Mode Database when using AD Groups as Site Collection Administrators https://blogs.technet.microsoft.com/dawiese/2018/09/27/test-spcontentdatabase-false-positive-for-classic-mode-database/