Edited 2/1/2012
This technique may cause problems with your farm. Please read all the comments before you follow the instructions in this post. -tk
One of my more popular blog posts is about getting rid of the GUID at the end of SharePoint 2007 central admin content database. DBAs world round sang my praises. There were statues put up in my honor, and babies, boy and girl alike, were named in my honor. It was a good day.
Then SharePoint 2010 came out. If you think SharePoint 2007 liked its GUIDs, wait until you install SharePoint 2010. In Shane and I's continuing quest to rid the world of GUIDs Shane recently posted a blog post on how to get the GUIDs out of your Search Service Application. It's too soon to see if it will take the world by storm or not. Not to be outdone, I'm writing this blog post to show how to fix the central admin content database the SharePoint 2010 way. Sit back, put your seatbelts on, and keep your arms and legs inside the ride at all times, it's gonna get crazy in here for a few minutes.
First, let's identify the enemy. Here it is in its natural habitat:
Oh my, look at all those GUIDs! My eyes!!! Looks like I have plenty of blog posts in my future.
The process for fixing this in SharePoint 2010 pretty much the same as it was in SharePoint 2007, though now we have PowerShell at our disposal, so it's a lot easier, and let's face it, cooler. The first step is to create a new, GUIDless, content database for Central Admin:
Text:
New-SPContentDatabase -Name SharePoint_AdminContent -WebApplication http://sharepoint:1026
Now we need to coral all the site collections in the current GUIDed content database and shuffle them over to our shiny new content database. In SharePoint 2007 we had to use STSADM to do this, and we had to manually edit text files. STSADM and text files are for chumps. We have PowerShell, let's use it. First we need to get the names of our content database. My first thought was to use Get-SPContentDatabase, but it has an interesting wrinkle to it, wisely, like Get-SPWebApplication, it doesn't include central admin in its output. To get the central admin content databases we need to explicitly tell it that's what we want.
Here we can see that our central admin content databases aren't returned by Get-SPContentDatabase unless we pipe it through Get-SPWebApplication. We can see that there are two site collections in the GUIDed content database; central admin itself and the help site. If we want to banish that database from our SQL server, we'll have to move them both to the safety of a GUIDless database. Here's how that process went:
I tried a couple of things here. You can see that Get-SPSite doesn't recognize the central admin content database by name. SharePoint really goes out of its way to keep you from mucking things up. It does however recognize it by its ID, so we'll use that. The last line is where all the magic happens. I get a collection of all the site collections in the GUIDed content database and pass them to Move-SPSite and tell it to move them to the GUIDless content database. That's about 100x easier than the same method in STSADM. Maybe 101x easier. Here is the command I used for your copying and pasting pleasure:
Get-SPSite -ContentDatabase e2e716d7-4e04-4f22-acdd-6730dee176a8 | Move-SPSite -DestinationDatabase 94d1a9d6-d755-4fa8-9356-e52f56db5c54
Hopefully your database IDs will be different. J I had to use the database IDs instead of their names since a lot of the cmdlets won't recognize the central admin database names. After you run the IISRESET verify that central admin renders and everything is fine. Then use Remove-SPContentDatabase to put the final nail in the coffin of that GUIDed content database.
You can see I verified the two site collections were moved over before I removed the content database. It's also important to note that I used Remove-SPContentDatabase instead of the more popular Dismount-SPContentDatabase. Remove-SPContentDatabase actually deletes the database on the SQL side, which was the purpose of this whole exercise in the first place. It does forewarn you that it's doing it, so it's all above board. Here is the final proof that our campaign was successful:
No GUIDed AdminContent as far as the eye can see. Chalk up another victory in the battle against GUID abuse.
tk