WSS MSDE DB Location Change Nightmare

Long story, well made as short as possible.

New server 12 GB (OS partition) & 500GB (Data drive). Default Windows
Sharepoint Services (WSS) was installed (with MSDE). This default
installation placed the STS_Config and STS_servername_1 DBs on the C:\ (OS
Partition).

The goal - move these two DBs to the D:\ where they can live and grow
happily for quite some time. How hard could that be???

I found and followed MS Article ID: 843580 "How to change the location of
the Windows SharePoint Services database files"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;843580

After completing the steps outlined in the article I recieved the following
error when attempting to connect to the sharepoint site: Unable to connect to
database. Check database connection information and make sure the database
server is running. For tips on troubleshooting this error, search for article
823287 in the Microsoft Knowledge Base at http://support.microsoft.com.

So I did and followed the steps in MS Article ID: 823287. MSDE was running
and IIS 6 (it is 03) is not in isolation mode. Therefore Method 3 was sure to
be the culprit: Make Sure That the Account That Is Used By the Application
Pool Is the Account That Has the Required Permissions to the SQL Server
Database.

I started messing around with the Application pools and verifying the
account that is used on those.
I also spent some time in the "SharePoint Central Administration" page and
reset the Set default content database server and the Set configuration
database server without success.

I then decided to try to install SQL enterprise manager on this server to
see if that would tell any tales. Well it did. I found the STS_Config and
STS_servername_1 DBS were not attached to the \sharepoint instance of MSDE.
So I re-attached then using the Enterprise manager and verified that the
"predefined" Network Account had owner access. I thought for sure that I had
it fixed!

But alas, I still get the "Unable to connect to database" error.

In addition to these symptoms I am getting the following errors in the
Application log (everytime a connection is attempted to the sharepoint site):
"#50070: Unable to connect to the database WSSConfigDB on SqlsServer. Check
the database connection information and make sure that the database server
is running.

I found an article on wss.collutions.com that said to verify the Sharepoint
Timer Service is not running in the same account as the WSS Admin App Pool
account. Which I did again without success (I set the timer service to run
under the local service as well as an adminstrative account).

This same article mentioned "This behavior occurs if the version of the
Oledb32.dll file on the computer is not 2.8 or a later version" which I very
reluctant to do anything about since this server was working just fine until
I tried to move the DBs.

Anybody have any thoughts? What have I done?

My gut tells me that I messed something up with the Application pools in
IIS. Does anybody know what/how the 'default application pool' is supposed to
be setup? Do I want to be using the predefined Network account for everything?

Do I need to setup a new application pool?

Are there any tests that I might try to verify DB connectivity?

Does anybody know if I completely remove all traces of sharepoint and MSDE
and reinstall (pointing the MSDE DB locations to the D: data drive of course)
and then pull the old "swtich a roo" by stopping the SQL service instance and
then putting a copy of the MDF and LDF files in place of the new ones, will
this work? My gut tells me that the MDF file has the location of the LDF file
in a table and therefore this will not work.

I would like to do everything in my power to not have to recreate this
entire site from scratch.

Thanks in advance for any thoughts and/or suggestions.

-KC
.

Relevant Pages

  • Re: Help with WSS 3.0 Server Farm Config - Backend SQL 2005
    ... I had to use only "sharepoint" to get the ... What interest me though is that the database get created but fails after ... Virtual Server with DBSVR ... an account local to the WEBSVR) to create and access the SQL server, ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: WSS MSDE DB Location Change Nightmare
    ... STS_servername_1 database. ... able to do your reinstall of MSDE and restore over top of the new Content DB ... Sharepoint Services was installed. ... Pool Is the Account That Has the Required Permissions to the SQL Server ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Restored Server but SharePoint refusing admin access
    ... I went ahead and forwarded my post to the SharePoint forums. ... SID/BID or remove the user from the database and add it again. ... you had) you cannot access the database from that account. ... newly added administrator account (for me, since I added a new admin account ...
    (microsoft.public.windows.server.sbs)
  • Re: WSS MSDE DB Location Change Nightmare
    ... After the STSADM backup do I want to run an uninstall, ... I.E all MSDE/SQL references and the MS WIndows SHarepoint Services 2.0? ... STS_servername_1 database. ... able to do your reinstall of MSDE and restore over top of the new Content DB ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: ADP/SQL Server 2000 Security Problem
    ... The server is running Windows 2003. ... I'll also test using a SQL Server account and see what happens. ... it worked in MSDE 2000. ... I have not created any new accounts for the production database. ...
    (microsoft.public.access.adp.sqlserver)
Loading