SharePoint 2010: Rename the SharePoint State Service Database

Continuing on a quest to rename everything in SharePoint. You can find the first article here.

Rename the SharePoint State Service Database

The State Service in SharePoint 2010 is a service application that manages user state across browser requests. The SharePoint State Service is required by InfoPath Forms Services, the Chart Web Part, and certain Visio 2010 scenarios. You can find the State Service in Central Admin under Application Management – Manage Service Applications. There will be one or more State Service applications and associated proxies.

As usual, if the state service was created by the SharePoint Configuration Wizard, or you create it without editing the database name, the database will be created with a GUID on the end, such as:

StateService_5536604e93df4369a916cf408e0c3866  (ew!)

So let’s check out our state service in PowerShell. Open the SharePoint 2010 Management Shell (Start –> All Programs –> Microsoft SharePoint 2010 Products –> SharePoint 2010 Management Shell). To start, try a simple:

Get-SPDatabase | Select Name

This will list the SharePoint databases, and you should easily spot your State Service database. If for some reason you don’t know the name of the State Service Database, you can list all state service databases with this command:

Get-SPDatabase | Where-Object { $_.Type -eq "Microsoft.Office.Server.Administration.StateDatabase" }

Every SharePoint object has an ID (a GUID), and the easiest way to get a reference to a SharePoint object is by using that ID. You can get the ID for databases with this command:

Get-SPDatabase | SELECT Name, ID

Once you find the ID for your State Service Database, you can get a handle on it with this command:

$db=Get-SPDatabase -id {guid}

Next (and this is a common step with SharePoint Service databases; the trick is always figuring out how) you have to dismount the database:

Dismount-SPStateServiceDatabase -Identity <DatabaseID>

For “DatabaseID” you can either paste in the GUID we copied earlier, or you can use the $db variable as a hook to the database itself. $db.Id won’t work unless you cast it to a string first.

You’ll be asked to verify that you want to do this:

Are you sure you want to perform this action?
Performing operation "Dismount-SPStateServiceDatabase" on Target "SP_Dev_StateService_DB".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):

A simple “Y” and enter will dismount the database. Now you can go to SSMS to rename the database — right-click on the database and select “Rename” or in T-SQL:


After you’ve renamed the database, then mount it again with the command

Mount-SPStateServiceDatabase -Name "<DatabaseName>" -DatabaseServer "<ServerName>"

And you’re all set.

If you completely screw up the database somehow, or feel it’s corrupted, there’s no critical data in the database – simply delete it and create a new one with the command:

New-SPStateServiceDatabase -Name "<StateServiceDatabase>" -ServiceApplication $serviceApp

Which will create a state service database and associate it with the State Service.

Verifying SharePoint Mirroring Database Status

SharePoint mirroring links SharePoint 2010 to the status of mirrored databases in SQL Server 2008 and above. Database mirroring is a high availability strategy where two SQL Servers are configured to remain in sync so that if the master server fails, the mirror server is able to pick up with either minimal or no lost data. You can learn more about SQL Server high availability strategies, including mirroring, in this TechNet article or Professional SQL Server 2012 Administration (Wrox, 2012).

SharePoint Server 2010, unlike previous versions, is “mirror aware” – prior to SharePoint 2010, when a database failover event happened, you had to manually reconfigure the SharePoint servers to point to the mirror instances of the databases. With SharePoint 2010, once configured, if the primary database fails over to the mirror, SharePoint will automatically detect the failure and connect to the mirror database instance. You can read more about SharePoint availability with SQL Server database mirroring in this TechNet article.

I recently had 18 SharePoint farms and 135 servers to configure and verify, so checking over the status of all the mirrors for failover was looking pretty daunting, until I figured out this little trick.

SQL Server 2008 R2: List SQL Databases

The first step is to open the SQL PowerShell provider on the Farm’s database server. Start –> Run –> sqlps will open the PowerShell window. Alternatively, open SQL Server Management Studio (SSMS), connect to an instance, then right-click on the “Databases” folder in the Object Explorer and select “Start PowerShell.”

If you open PowerShell with “sqlps” you will start in


You’ll have to navigate down to the Databases node, using the CD command – first change to the SQL folder:


Then you’ll want to change to the server and instance. You can either CD to the server, then to the instance, or both at once:

PS SQLSERVER\SQL:> CD Server\Instance

(If you only have one instance, or you want the default instance, the instance is “Default”)

Finally we’ll change to the databases folder:

PS SQLSERVER\SQL\Server\Instance > CD Databases

(Note that at any time you can see what folders are available using the Dir command, or the PowerShell Get-ChildItem or GCI for short)

Now that we’re on the databases folder, we want to list all the databases on the server, with some specific attributes.

gci |
SELECT Parent,
    MirroringStatus |
Sort-Object Name |
Export-CSV Database_List_$env:computername.csv

We’ll use the GCI command and pipe it to a SELECT statement to choose the attributes we want. Then we pipe that result to a Sort-Object cmdlet so that our databases are sorted in alphabetical order.

Finally we pipe that to Export-CSV to create a CSV file with our database list, which we’re going to use in a minute. (Note the use of the env:computername variable to generate a unique filename in case you’re collecting these from a number of servers)

Once we have that csv file, we’ll head over to our SharePoint 2010 farm to check on the status of all the SharePoint databases, and compare them to what we have on our SQL Server.

SharePoint 2010: List SharePoint Mirror Status for Databases

On any of the application servers in your SharePoint farm, open the SharePoint Management Shell (Start –> All Programs –> Microsoft SharePoint 2010 Products –> SharePoint 2010 Management Shell). The script we want to run here is similar to the script we ran on the SQL Server:

Get-SPDatabase |
SELECT Farm, Name, Type, FailoverServer |
Sort-Object Name |
Export-CSV Database_List_$env:computername.csv

The cmdlet “Get-SPDatabase” lists all the SharePoint databases, or “all the databases SharePoint knows about.” We’re selecting the farm name (just in case we need help keeping the files straight), the database name, the database type (similar to TypeName), and the FailoverServer property, which indicates which SQL Server has been configured as the mirror server (the database names must be the same). Then we sort by database name and export the lot to a csv file.

Now we have a csv file listing the databases on the SQL Server, and another file listing the databases for our farm.

Comparing the Two

Open both csv files into Excel (just double-clicking on them will do). Then click the “View” tab, and click “View Side by Side” – a dialog will open asking which spreadsheet to compare with – select the other csv file. You want the two spreadsheets next to each other horizontally, as shown below. If you end up with them tiled vertically, click the “Arrange All” button on the View tab and select “Vertical” then click “OK” – you should end up with the two spreadsheets looking like the below:


This next part is important – the list of databases in SQL Server will most likely be longer than the databases from SharePoint (since all the SharePoint databases are in SQL Server, but not vice versa).

Next, open up the “Name” column in each spreadsheet – you’ll see several databases with the same name. The next step is to line up the matching databases by inserting blank rows in the SharePoint database list so the SharePoint databases line up with their matching SQL Server databases, as shown below.


Now that we have the two sets of databases aligned, we’re going to combine them into a single table with a bit of Excel magic. First let’s delete the first row of each file – the #TYPE directive from our PowerShell output. Next, on our SQL Server database list, click in cell A1 (or select the whole table, but clicking in the top left cell is easier). Then on the Home tab of the ribbon click “Format as Table” and choose a table format. You’ll get the Format As Table dialog indicating the range (if you just had A1 selected, it should automatically select the whole populated range). Make sure “My table has headers” is selected, then click OK.


You should now have a formatted table of your SQL Server databases that looks similar to this:


Now select the data from your SharePoint table – click and drag to select the full range, then Ctrl-C to copy it. Next click in the top cell next to the table in the SQL Server database list:


Ctrl-V to paste the range from the SharePoint database list – the table formatting should expand to include the pasted data:


Expand the columns so you can read the data – now you have a full report of the status of the databases in your farm, as well as the status on SQL Server. If you’re mirroring SharePoint databases, this is a great way to check a full status of your farm databases (shown below with several columns narrowed for display purposes)


  • SharePoint databases that don’t have a Failover Server haven’t had mirroring set up.
  • SQL Server databases that don’t have a matching SharePoint database may be orphans from removed services or site groups
  • Verify the mirror status of SQL Server databases that you need to set SharePoint mirroring on.

When you have a number of farms you’re configuring, and especially if you have to rely on those wily DBAs to set up mirroring, this is a quick and dirty way to review a complex configuration issue.