How to remove the GUIDs from the SharePoint search service application databases

Update 12/6/2010 - Found an issue after you finish these steps where you get an error in logs. The error doesn't break anything and is just annoying. To clear that error check out this post - Correcting SharePoint 2010 Search Database Error.

WARNING: This is pretty hardcore stuff and I have only tried it in a handful of environments. While the process has been successful for me that doesn't guarantee it will be successful for you. I highly recommend you try this in a dev environment before running it in production. If you are building your farm fresh that is the best time to do this. If you screw it up you can delete the search service app and try again. If you have a running a production farm already tread lightly. Also, I am pretty sure Search will be unavailable for the entire time you are doing these steps so plan accordingly. Don't be scared. This will work; you just need to play it safe.

So I don't know about you but I am on to SharePoint's game. It has a secret goal to run the world out of GUIDs. Well, being a proud citizen of the world I am here to help save unnecessarily wasted GUIDs so developers can continue to use (unnecessarily?) them for years to come. (And to think, you thought I hated developers. This is clearly for their benefit.)

My partner in crime Todd and I have been working in our secret lair on this very topic. And while we are not completely ready to share all of our findings I am proud to publish one of the first pieces. How to get rid of the GUIDs in the Search database names. There is an article on TechNet that talks about how to rename or move the service application databases but, I had a hard time following it and getting it to work so I thought I would post a little easier to follow version.

For this post I created a Search service application call Blog Search Service App using Central Administration. After it completed I was stuck with the following three databases with those unnecessary GUIDs stapled on the end.

Renaming the Crawl Store database

 

  1. In Central Admin go to manage service applications
  2. Click on your Search service application
  3. Scroll down the page and click on modify under Search Application Topology
  4. Under Databases click on your Crawl Database and from the drop down click Edit properties
  5. Find the database name and simply highlight the GUID and hit delete
  6. Click OK

When you return to the manage topology screen you will see pending update. The change will not be committed until you click the Apply Topology Changes button at the bottom of the screen. Don't do it yet though, lets rescue another GUID first.

Renaming the Property database

 

  1. Assuming you are still on the same page from the last step
  2. Under Databases click on your Property Database and from the drop down click Edit properties
  3. Find the database name and simply highlight the GUID and hit delete
  4. Click OK

Now all that is left is to scroll to the bottom of the page and click Apply Topology Changes. This will probably take a couple of minutes to run. So just kick back for a moment and think of what better planet you left for the children by saving these two GUIDs. It may take a while to run depending on the state of your databases. Mine took about 6 minutes on empty database for my VM.

Here is a screen shot of the results. That was really pretty painless too bad the next one is not.

Renaming the Admin database

Put on your big boy pants because this one is going to require some ninja like SQL and PowerShell skills. (Or I guess you can just cut and paste what I have here.)

  1. On your SQL Server open SQL Server Management Studio
  2. Find your Search admin database. From the screen shot mine was named Blog_Search_Service_App_DB_fe289c49b61344b48952a546e48e0135. Right click on it on the database and select Tasks > back up…
  3. Back the database up. If you are unsure how to do this the defaults should work fine so click OK.
  4. At the backup successful message click OK
  5. Scroll up to Databases, right click and select Restore Database…

  6. Click the radio button for From device: and the click the … button to the right.

  7. Click Add
  8. Now select the backup file you just created. If you just clicked OK on the backup screen SQL should open right to the file for you. Once you find it click OK.
  9. Click OK on Specify Backup
  10. Check the box under Restore next to your backup
  11. Now look toward the top of the window and enter your new database name in the To database field. For the example I entered Blog_Search_Service_App_DB. Double check yourself in the screen shot below.

  12. Click OK
  13. At the successful screen click OK

The SQL hard work is over but don't close management studio quite yet. You will need to come back to delete the old database in a little bit.

  1. Now go back over to your SharePoint server
  2. Open the SharePoint Management Shell by clicking Start > All Programs > Microsoft SharePoint 2010 Products > SharePoint 2010 Management Shell
  3. Now enter the following line of PowerShell remembering to change the identity to your service application name:

    $searchapp = Get-SPEnterpriseSearchServiceApplication -identity "Blog Search Service App"

  4. Now enter the following line of PowerShell (it might take a minute to run):

    $searchapp.Pause()

  5. Now enter the following line of PowerShell remembering to update your database name and database server:

    $searchapp | Set-SPEnterpriseSearchServiceApplication -DatabaseName "Blog_Search_Service_App_DB" –DatabaseServer "2010server"

  6. Now enter the following line of PowerShell:

    $searchapp.Resume()

  7. Double check yourself in the screenshot below.

  8. Now before you continue you need to make sure the database change is complete. The best way to do this I believe is to use this PowerShell:

    Do {write-host -NoNewline .;Sleep 10; $searchInstance = Get-SPEnterpriseSearchServiceInstance -Local} while ($searchInstance.Status -ne "Online")

     

This will display a . every 10 seconds until all of the search components return to an online state. It might take a few minutes but be patient.

 

Now jump back over to the SQL Server to delete that final database with a GUID and restore peace and order to society.

  1. In SQL Management Studio find the database with the GUID, right click on the name, and click Delete. (If you are the nervous type backing it up first isn't the worst idea you have had today.)
  2. Check the box at the bottom for Close existing connections and click OK.

 

Hooray! No more nasty GUIDs.

 

<Insert witty ending here. Something of the style of Batman and Robin. Todd is Robin of course, he makes a great boy wonder in his shorty shorts. >

 

Shane

SharePoint Consulting

Comments

# re: How to remove the GUIDs from the SharePoint search service application databases

Wednesday, September 29, 2010 7:54 AM by Mai Omar

Very interesting Shane.. i bought your book ..

and you todd and steve about SharePoint administration 2010..

i like so much the monitoring chapter.. i haven't finished it all.. but till now.. amazing really...

keep it up all..

With my regards;

Mai Omar

Title: Senior Solutions Developer

Company: ITEgyptCorp

Blog: http://maiomar.itegyptcorp.com

# Getting the GUID out of the AdminContent database in SharePoint 2010

Wednesday, September 29, 2010 10:35 AM by Todd Klindt's SharePoint Admin Blog

Body: One of my more popular blog posts is about getting rid of the GUID at the end of SharePoint 2007

# re: How to remove the GUIDs from the SharePoint search service application databases

Wednesday, September 29, 2010 12:42 PM by Robert

Thanks for the info.  Who are these nimrod MSFT PM's that think databases need to have unique GUID's for the entire f'ing universe?  Give us a break!

/rant

# re: How to remove the GUIDs from the SharePoint search service application databases

Wednesday, September 29, 2010 2:10 PM by KomatoZo

Thanks, great article. Anyway it would be better to not create them with those GUIDs =)

# Database cannot be found errors

Tuesday, October 05, 2010 1:52 PM by Mike Pasco

Thanks for the post Shane. I gave this a shot in a new test farm with a new search service application and everything went well. However, today I am starting to see errors in the application event log that SharePoint is trying to open the original search admin database with the guid in its name. I've looked at the ULS logs and it appears to be happening when a Health Analyzer rule kicks off to check for database server drive space (Microsoft.SharePoint.Administration.Health.SqlServerDrivesAreNearlyFull). Is this something you have come across yet?

# re: How to remove the GUIDs from the SharePoint search service application databases

Tuesday, October 05, 2010 7:47 PM by Jase

Should we wait until the process of renaming the Crawl and Property databases is complete before backing up the Admin database?

I haven't tried backing up the Admin database while the renaming is still in progress, but I suspect things would break if you did as the renaming process writes to the Admin database?

Cheers.

# Getting rid of GUIDs in SharePoint 2010 database names

Tuesday, October 26, 2010 3:59 PM by The SharePoint Farmer's Almanac

It is like your typical battle of good vs. evil. SharePoint 2010 has a secret plot to run the world out

# Getting rid of GUIDs in SharePoint 2010 database names

Tuesday, October 26, 2010 4:44 PM by Shane Young - The SharePoint Farmer's Almanac

It is like your typical battle of good vs. evil. SharePoint 2010 has a secret plot to run the world out

# re: How to remove the GUIDs from the SharePoint search service application databases

Thursday, November 04, 2010 4:01 PM by philippe

Hi,

I've done the same step to rename the search admin database.

however, Sharepoint still remember its old database and continuously log errors.

I tried with no success to remove it from SharePoint.

Do you have any idea?

Thanks a lot

# re: How to remove the GUIDs from the SharePoint search service application databases

Thursday, November 04, 2010 4:11 PM by Shane

Philippe I do have a fix for it but I haven't blogged it yet. Email me shane at sharepoint911.com and I will give you more details. I promise to publish the post soon for the masses.

# Search Database GUID issue

Monday, December 06, 2010 10:20 AM by The SharePoint Farmer's Almanac

So in the quest to have no GUIDs I wrote the blog post How to remove the GUIDs from the SharePoint search

# re: How to remove the GUIDs from the SharePoint search service application databases

Wednesday, February 16, 2011 1:00 PM by Shane

msmvps.com/.../search-database-guid-issue.aspx

This will tell you how to get rid of the error.

# re: How to remove the GUIDs from the SharePoint search service application databases

Monday, May 09, 2011 2:37 PM by Scott

What about all the rest?

Application_Registry_service

Bdc_Service

Managed Metadata Service

PerformancePoint Service Application

Secure_Store_Service

StateService

WebAnalyticsServiceApplication_Reporting

WebAnalyticsServiceApplication_Staging

WordAutomationServices

# re: How to remove the GUIDs from the SharePoint search service application databases

Wednesday, May 11, 2011 9:04 AM by Carlton

This was the only post I could find that actually had a workable solution for renaming the Search Admin DB.

BTW - I wasn't sure what my DB name was so I typed "Get-SPEnterpriseSearchServiceApplication" and it gave me all the info I needed.

Great Post. Thanks.

# Renaming SharePoint 2010 Databases (no GUID)

Wednesday, January 04, 2012 2:39 AM by Fatshark's Personal Blog

Changing database names is quite easy in SharePoint 2010 when creating a new Service Application. But for some Service Applications you simply cannot change easily the name for the DB. Link1 Link2

# re: How to remove the GUIDs from the SharePoint search service application databases

Wednesday, April 25, 2012 11:18 AM by Lonuel

Your snapshots no longer work. They are pointing to www.sharepoint911.com/.../

Leave a Comment

(required) 
(required) 
(optional)
(required) 
If you can't read this number refresh your screen
Enter the numbers above: