How to rename SharePoint 2010 … Everything!

This is the first in a series of articles to pull together all the various guides around the web to rename SharePoint 2010 databases, servers, services, and other objects. Over the coming weeks I’ll publish these articles:

  • Introduction & Windows PowerShell (this article)
  • Rename the Configuration and Content Databases
  • Rename the State Service Database
  • Rename Alternate Access Mappings
  • Rename Servers
  • Rename SharePoint Site Groups and Sites and IIS Sites
  • Rename IIS Application Pools

Why Rename SharePoint 2010 Objects?

As SharePoint 2010 installations grow in size, admins and DBAs are facing increasing frustration in dealing with Microsoft’s propensity to guarantee unique names by gluing GUIDs on the back of every name. This has gotten to be such an issue that half the reason the AutoSPInstaller script was created was to eliminate the GUIDs where possible. (Note that aside from simply being unattractive, names with GUIDs are a royal pain when you have to write scripts)

A standard SharePoint 2010 installation leaves nasty database names.

However, you may still end up with awkward names for various reasons. There are instructions on how to rename these artifacts scattered around the web; this is my attempt to gather everything into one place.

Windows PowerShell to Rename Content Databases and other SharePoint Objects

If you’re working with SharePoint 2010 and you’re not working with Windows PowerShell, it’s time to start. Virtually all the guidance here is PowerShell-based. I’ll be working with the SharePoint PowerShell provider, which has the SharePoint extensions enabled as well as the path to the 14 hive defined – it makes a great command prompt for SharePoint as well.

Some Windows PowerShell tips before we proceed. You will definitely want to understand piping. The short, simple explanation is that when you use the pipe character ( | ) between commands, it redirects the output of the first command into the second command.

So this script:

Get-SPDatabase | SELECT Name, ID

Returns all the SharePoint databases (Services Databases, Configuration Databases, Content Databases) from the current farm. Think of this as a collection of objects. This collection is then sent to the SELECT command, which will select out the Name and ID properties and list those for all the objects piped to it. Understanding the “way of pipes” will make a huge difference in your productivity with Windows PowerShell.

The other little tidbit about PowerShell and SharePoint objects are how to get the one you want. When you type Get-SPDatabase in the SharePoint Management Shell, you’ll get something looking like this:


Using the SharePoint 2010 Management shell.

So how do you get the one you want? The most popular way to pick out a specific object is to use the SELECT-OBJECT cmdlet, like this:

Get-SPDatabase | WHERE-OBJECT { $_.Name -eq "SomeDatabase" }

This line takes that collection of SPDatabase objects output by the Get-SPDatabase cmdlet, and pipes it to the WHERE-OBJECT cmdlet. That takes the collection of objects and uses the statement in curly braces to filter out the database we’re looking for. (“$_” is shorthand for “the current object”)

[amazon_enhanced asin=”1118021983″ container=”AmazonTable” container_class=”alignleft” price=”New” background_color=”FFFFFF” link_color=”000000″ text_color=”0000FF” /]

The problem, of course, is that we have these nasty GUID names to deal with, so we’re going to be copying and pasting from the list of databases. If we have to copy and paste anyway, then we can cut to the chase with this command:

Get-SPDatabase -ID c3c72c94-513b-4ff1-9346-3646f1bdc7ff

This gets us one of the Content Databases – in this case the one for the Central Admin site. The ID is a GUID, and easily selectable to copy and paste from the list. This is the second way to return a specific database, and until we get the names trimmed down, it’s the most straightforward. In addition, the –ID parameter is available for virtually every SharePoint object type, and will obviously always be unique.

With that under your belt, next time we’ll tackle renaming the SharePoint Content Databases, and I’ll address why you should never rename a SharePoint Farm Configuration Database.