A recent support case in our European division involved a customer wanting to rename their SharePoint SQL databases (the current names had GUIDs in them and that just wouldn’t do). They tried to do it using these steps but unfortunately the results were less than favorable.
Seems the procedure worked for Content and Admin DBs, but in the case of this customer it failed for the WSS Config DB. The article mentions using stsadm commands that are declared as obsolete in the SharePoint docs, and have detrimental affects on the Config DB:
stsadm -o deleteconfigdb
stsadm –o setconfigdb -connect –databaseserver target_SQL_server -databasename databasename -farmuser your_farm_sql_account -farmpassword your_farm_sql_password
The SharePoint docs actually recommend alternative commands to these which use psconfig instead (comments on the aforementioned BLOG post mention this as well):
psconfig.exe -cmd configdb –disconnect
psconfig.exe -cmd configdb -connect -server <Server_name> -database <Database_name> -user <DOMAIN\username> -password <password>
Unfortunately, this also does not work 100%: it successfully connects the Config DB and everything SEEMS OK, but it causes issues with the Sharepoint Timer Service which fails to login and eventually floods SQL with login failures. The root cause is that there are still some reference to the old name of the ConfigDB (as Data Sources) in the ConfigDB itself. You can fix it by manually running queries on the ConfigDB to replace the entries but, as you might expect, this is not supported.
Sooo, what’s the point of this post you may ask? Well, to alert you to the above issues and remind you that the official procedure for MOVING (not renaming, mind you) Sharepoint DBs is here:
Renaming the Sharepoint DBs (actually the Config DB is the problem) is not a recommended thing. Refer to the following KB article for further details: http://support.microsoft.com/kb/841057/en-us.
(Special thanks to Liviu Coconu and Ladislau Szomoru for their contributions to this post.)