New SharePoint Config DB on pre-existing server


Today I had the pleasure of having to deal with a SharePoint test environment whose Config DB had a corruption. Being a test environment, and knowing that it was quite old and crufty as far as Test environments go, I decided the best way to deal with it was to kill the Config DB and create a new one, re-attach the content dbs and go from there.

A couple of points about this situation:
- the SharePoint environment is a single server environment (with SQL 2000 Standard running)
- I didn't want to set up an entirely new SharePoint server, simply use the current one keeping all the other stuff already running on it
- When re-creating the Config DB, I renamed it to a new naming standard

So I went about disconnecting the server from the farm by using the SharePoint Products and Technologies Configuration Wizard. This is a relatively straight-forward, wizard based task.

I re-ran the SharePoint Products and Technologies Configuration Wizard, this time creating a new farm with the desired Config DB name (SharePointTest_Config).

I then performed the usual initial tasks against the Config DB - create an SSP, set up index services, etc.

I then wanted to reconnect the content db's from the previous test config db. This is done by creating the first Site Collection, with the desired IIS config (port 80, host header, etc). It is well documented that you then need to remove the default content db, and attach your original content db with an stsadm command:

stsadm -o addcontentdb -url [url] -databasename [sqldbname]

The following error would result:

Cannot open database requested in login '[oldconfigsql_name]'. Login fails. Login failed for user '[farm_account]'.

The same error would appear in SharePoint's log files when you try to create a content db using Central Admin.

The culprit is a registry setting that stores the DSN that points to the Config db. The process of using the SharePoint Products and Technologies Configuration Wizard to create a new config db apparently doesn't update this DSN, but it is used when performing the stsadm -o addcontentdb command.

The registry key to look for is:

HKEYLOCALMACHINESOFTWAREMicrosoftShared ToolsWeb Server ExtensionsSecureConfigDb

Update this to point to the new SQL db, and re-run the stsadm -o addcontentdb command, and you should then see the magical "Operation completed successfully." message.