Renaming the Managed Metadata Service Application Database

author Andy Dawson calendar Dec 14, 2011 · 3 min read · Managed Metadata Service PowerShell SharePoint Sharepoint  ·
Share on: linkedin copy

On the face of it, renaming the Managed Metadata Service Application database in SharePoint should be a fairly simple matter. There’s a test box for the database name in the properties of the Service Application and changing the name shown changes the database name. There are however one or two issues with changing the database name this way…

The image below shows a minimally configured Managed Metadata Service Application instance (some sample data has been added):

Sample Managed Metadata Service Application

The database name can be easily changed by editing the properties of the Service Application and editing the name of the database:

Sample Managed Metadata Service Application Properties

The first of the issues experienced is that SharePoint now knows about two Managed Metadata Service Application databases. Checking the database list within the ‘review database status’ area of the ‘upgrade and migration’ section of Central Administration (a good place to get a complete list of the databases associated with a SharePoint 2010 farm) shows two Managed Metadata Service Application databases:

SharePoint believes that it has two Managed Metadata Service Application databases

In addition, if the old database is deleted (using SQL Management Studio), the message ‘Not Responding’ will be shown against the database in the list (and errors will be shown in the event viewer of the machine hosting the Managed Metadata Service):

Managed Metadata Service Application database showing 'Not Responding'

This is logical as SharePoint understands that there is a database associated with the farm that has been deleted.

The real problems have, however, only just started!

Looking at the Managed Metadata Service Application now shows the following:

Empty Managed Metadata Service Application

In other words, although the database associated with the Service Application has been changed, the data contained within the original database has not been migrated. SharePoint has simply created a new Service Application database and associated that with the Service Application. If the database is renamed before any data has been added to the Service Application, this is not an issue, you’ll simply have to add administrators and data as you would normally. You’ll also have to remove the original database using the following PowerShell:

  1. Get-SPDatabase
    Note the GUID of the original Managed Metadata Service Application database
  2. $OldDB = Get-SPDatabase
  3. $OldDB.Delete()

To correct the issues shown above after renaming the database, assuming that the original database is still available, there are a couple of potential routes to take:

  1. Perform steps similar to those outlined in the blog post ‘Renaming the PerformancePoint Service Application database in SharePoint 2010’ – I’d suggest the ‘backup and restore’ procedure from this blog post. Also note that the PowerShell command you’ll need to assign the newly renamed database to the Service Application is Set-SPMetadataServiceApplication –DatabaseName
  2. Temporarily reattach the original database to the Service Application and export the data from it, before reattaching the new database and importing the data into it.

The PowerShell you’ll need to achieve the latter of the the above methods is:

  1. Set the Service Application to use the original database:
    Set-SPMetadataServiceApplication "<friendly name of the Managed Metadata Service Application" -databasename
  2. Issue an IISRESET on all servers in the farm
  3. Export the Managed Metadata Service Application information:
    Export-SPMetadataWebServicePartitionData -identity -ServiceProxy “friendly name of the Service Application Proxy” -path .cab
  4. Set the Service Application to use the new database:
    Set-SPMetadataServiceApplication "<Friendly name of the Managed Metadata Service Application" -databasename
  5. Issue an IISRESET on all servers in the farm
  6. Import the Managed Metadata Service Application information:
    Import-SPMetadataWebServicePartitionData -identity -serviceproxy "friendly name of the Service Application Proxy" -path .cab –OverwriteExisting

Note that using this method retains the original data in completeness, therefore all of the list associations with the Managed Metadata Service Application should continue to function without needing to be reconnected.

You can then delete the original database using the PowerShell commands detailed previously.