I had a mission to achieve overnight; move 28 site collections into a new managed path, as well as rename the 28 associated content databases.\u00a0\u00a0 Pretty straightforward to do, and to script in advance to run in stages:<\/p>\n
After enough jolt cola to get that turtle to beat the hare fair and square, I got to the bottom of the problem.\u00a0 First the problem.\u00a0 The site collections could not be restored into their original database, as the site collection purportedly already existed there.\u00a0 Even though it was deleted.<\/p>\n
By midnight I gave up, and did the 28 Restore-SPSite into any random content databases, tossing organization and structure to the winds (temporarily), knowing I\u2019ve got gads of available storage, knowing once I got to the bottom of the issue, a simple set of move-spsite commands would set things right.\u00a0 No, I don\u2019t like randomness, but I also like a few winks of sleep and happy users\u2026<\/p>\n
Now the cause.\u00a0 I\u2019m running SharePoint 2010 SP1, which has the ability to recover deleted site collections (not through the UI, but only through PowerShell).\u00a0 I used the -gradualdelete option, thinking I would be nice and gentle with a production farm.\u00a0 Here\u2019s a sample of my delete commands, where I also disable prompting:<\/p>\n
Remove-spsite&nbsp; href=\"http :\/\/SharePoint\/div\/clm\/int\/A\/\" &nbsp;-confirm:$false -gradualdelete\r\n<\/pre>\nHere\u2019s the kicker.\u00a0 After the delete, the site collection is indeed still there.\u00a0\u00a0 It sticks around actually for the duration of the the Recycle Bin duration (default 30 days).\u00a0 There\u2019s one good way to see, let\u2019s dive into the forbidden content database, and have a peek:<\/p>\n
SELECT [DeletionTime]\r\n,[Id]\r\n,[SiteId]\r\n,[InDeletion]\r\n,[Restorable]\r\nFROM [Content_mydivision_a].[dbo].[SiteDeletion]\r\nwhere (Restorable=1)<\/pre>\nRestorable=1 indicates this site collection could be restored.<\/p>\n
The solution?\u00a0 Well, it\u2019s not the recycle bin job, that has no effect on this.\u00a0 There is a gradual delete job at the web application level, but that won\u2019t help us either; at least not just yet.\u00a0 First you have to use the remove-spsite CmdLet to remove each site permanently.\u00a0 Here\u2019s the syntax:<\/p>\n
remove-spdeletedsite f5f7639d-536f-4f76-8f94-57834d177a99 -confirm:$false\r\n<\/pre>\nAh, you don\u2019t know your Site Collection GUIDs by heart? well, me neither, I prefer more useful allocation of brain cells, so here\u2019s the command that will give you the Site Collection GUIDs that have been (partially) deleted:<\/p>\n
get-spdeletedsite -webapplication \"http :\/\/SharePoint\/\"\r\n<\/pre>\nSo, you got your partially deleted GUIDs, you diligently did a remove-spdeletedsite for each, but the Restore-SPSite still will not work.\u00a0 Now\u2019s the time to run the handy-dandy Gradual Delete timer job for your web application, in Central Admin, Monitoring.\u00a0 First thing you might notice is the job is taking a bit of time to run.\u00a0 That\u2019s good, it\u2019s doing something for you, and actually triggering the Content DB Stored Procedure called proc_DeleteSiteCoreAsync.\u00a0 It actually deletes in batches.<\/p>\n
Here\u2019s how to wipe out all these mildly annoying site collections from your recycle bin for a web application:<\/p>\n
get-spdeletedsite -webapplication \"http:\/\/ma-srv-sp10\/\" | Remove-SPDeletedSite\r\n<\/pre>\nAt this point your Restore-SPSite will work to your target content database, and if you played SharePoint Roulette like me and restored to a random location, a move-SPSite will make fast work of putting things where they should be.<\/p>\n