Deleting a Phantom Site Collection

Note: As I was writing this post I found this TechNet discussion which makes it sound like you can simply remove and then re-add the content database to the web application in Central Admin to resolve this problem. That makes a whole lot of sense, and you should definitely try it before following my instructions below! However, as I didn't find that link until after the fact and found plenty of other stumped developers while debugging, I'm still publishing this post in the hopes that it will help others find a useful resolution more quickly.

I had to rebuild a development VM this week, and sometime during the process I wound up with a phantom site collection. By that, I mean that Central Admin said that it existed, but didn't actually know anything about it - it showed up in the list of site collections, but with no information next to it. When I tried to delete it via Central Admin, it showed up in the list but when I selected it the "Delete" button remained disabled. This seemed very weird - especially since I'm 99% sure I created the site collection via the UI and can't imaging what went wrong - but I just decided to let it go and ignore that particular site collection going forward.

Unfortunately, subsequent tasks involved running PowerShell scripts which all broke when coming across that site collection. When doing anything with the SPSite object, I'd get a DirectoryNotFoundException with the following info: <nativehr>0x80070003</nativehr><nativestack></nativestack>

In order to avoid lots of current and future pain, I figured I'd need to clean this up. At first I tried a few basic PowerShell commands. Get-SPSite successfully returned an object with a GUID, but performing any other operations on it resulted in the same exception, so the Remove-SPSite cmdlet did not work. Then I tried going back to using STSADM but the deletesite, databaserepair, and even the super secret deleteconfigurationobject operations all failed me. In the end, unfortunately I figured I had to break the golden rule and modify the SharePoint databases directly.

It was very scary, but I was able to resolve the problem without too much difficulty. I found no trace of the site collection in the content database, but did find a row containing the site collection's GUID in the configuration table's SiteMap table. All it took was one very simple SQL query to fix things up: DELETE FROM <Database>.[SiteMap] WHERE Id='<Site Collection GUID>'

After running this one query, Central Admin no longer showed the site collection as existing, and my PowerShell scripts started running successfully again.

Hopefully you'll never have to do this. Hopefully you'll never have to modify, or even look at, the configuration database. But if you ever do, remember to be very careful and take a backup before you touch anything!