Removing Orphaned Sites: PowerShell Replacement for stsadm -o deletesite
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:
- 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.
- Rename the site collection in the source farm so that the URL doesn't conflict, and both can coexist in the new SharePoint farm.
- 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/