Skip Ribbon Commands
Skip to main content

Quick Launch

Todd Klindt's home page > Todd Klindt's SharePoint Admin Blog > Posts > Getting the GUID out of the AdminContent database in SharePoint 2010
September 29
Getting the GUID out of the AdminContent database in SharePoint 2010

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

Comments

you can also just pass the CA app into Get-spcontentdatabase

e.g. Get-SPContentDatabase -webapplication http://machine:35515/
 on 10/6/2010 8:22 AM

Good work

Thank you very much.
 on 11/12/2010 7:32 AM

Brilliant!

I've been looking for a way to remove the GUID from the end of the AdminContent DB and this process works great.

Thanks!
 on 12/1/2010 3:57 AM

Re: Brilliant!

Thanks. :)

tk
Todd O. KlindtNo presence information on 12/15/2010 9:23 AM

sp_farm account?

Why are you using the service account?  Why not the sp_admin installer/maintenance account?  Are you putting out bad mojo?
 on 1/2/2011 12:44 PM

Re: sp_farm account?

I see we have ourselves a wiseguy. :)

You are correct, in production you should not be using the Farm account to be doing these sorts of things. You should have a user account that has permissions to perform these tasks. I'm not doing that in these screenshots because it is not a production environment. It's a single machine VM environment and I took a few shortcuts.

tk
Todd O. KlindtNo presence information on 1/2/2011 1:15 PM

WSS_Content_Application_Pools Role Missing

I'm having a problem with certain action related to application pool creation. According to this:
http://technet.microsoft.com/en-us/library/cc678863.aspx#Section4

The "GUIDless" SharePoint_AdminContent is missing the WSS_Content_Application_Pools role (at least it is on my server). Whenever an account is created that should be added to that role, an error is generated. Are you experiencing this as well? Is there some way to replicate that role into the new server?
 on 1/4/2011 5:35 PM

Re: WSS_Content_Application_Pools Role Missing

I was alerted to this problem a couple of months ago by Tony Franola. I haven't found a solution yet, sorry. :(

tk
Todd O. KlindtNo presence information on 1/6/2011 10:37 PM

Sike Mullivan

Dude!! Stop being such a cowboy!! : P Just use PSCONFIG

psconfig.exe -cmd configdb -create -server "<DBSERVER>" -database "SharePoint_Config" -user "<FarmUser>" -password "<FarmUserPW>" -admincontentdatabase "SharePoint_AdminContent" -passphrase "<YourCoolPassphrase>"
 on 1/12/2011 11:04 AM

Re: Sike Mullivan

That psconfig command will work too. Though since this blog post was about SharePoint 2010 I figured I'd better use PowerShell. Trying to expand my horizons and all that.

tk
Todd O. KlindtNo presence information on 1/12/2011 10:29 PM
1 - 10Next

Add Comment

Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title


Body *


Today's date *

Select a date from the calendar.
Please enter today's date so I know you are a real person

Twitter


Want a message when I reply to your comment? Put your Twitter handle here.

Attachments

 

 Please Support my Sponsors