Re: WSS MSDE DB Location Change Nightmare



Site Collections are just how they sound, they are a collection of sites.
They are the unit of scale within WSS. Site Collections have to be created
in Sharepoint Central Admin or with STSADM. The first site in a Site
Collection is the Top Level Site. The ones below that are called subsites
or subwebs. The admin guide will probably do a better job explaining it
than I can.

stsadm -o enumsites -url http://localhost

will tell you what site collections your site has. You can use stsadm -o
backup to back them up.

Since I don't use MSDE I'm not sure how to get it to install to D:\.
Someone else will have to chime in on how to do that. After you get MSDE
were you want it then you use stsadm -o restore to restore your site
collections.

good luck,
tk
"KC" <KC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1BC76829-9725-46AB-AAC2-FA6482DFC5B9@xxxxxxxxxxxxxxxx
Thanks Todd.

As I am pretty new to WSS, I am a bit confused by your term "Site
Collections". I have a single Sharepoint instance with 6 "subsites"
hanging
off the top level. However I have only a single sts_config and
STS_servername_1 database.

When you say re-install MSDE, I just need to re-run the stsv2.exe and
specify the D:\ for install?

If so, then my steps would be:
1) run the STSADM command to backup the DB's
2) run the stsv2.exe /datadir="path\\" (ie d:\msde\)
3) run the STSADM command to restore the DB's

Thanks again!
KC


"Todd Klindt" wrote:

I only ever use SQL, so I'm not 100% certain of how MSDE will work.

If you can do a backup of the database in Enterprise Manager you should
be
able to do your reinstall of MSDE and restore over top of the new Content
DB
to get your content back. Moving MDB files around is generally frowned
on
by DBAs. I've had to do it in a pinch once or twice and it's always
worked
for me, but I would certainly not recommend it.

If your WSS install is all on one server with MSDE you should be able to
run
the application pool as local system, as it will have access to
everything.

How many Site Collections do you have? You could also do STSADM backups
of
your site collections, reinstall MSDE to D: then use STSADM to restore
your
site collections.

Hope that helps,
tk
"KC" <KC@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:863CF6A5-3017-4F80-B8D0-E435A2977BAD@xxxxxxxxxxxxxxxx
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: 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)
  • WSS MSDE DB Location Change Nightmare
    ... Sharepoint Services was installed (with MSDE). ... the Windows SharePoint Services database files" ... Pool Is the Account That Has the Required Permissions to the SQL Server ...
    (microsoft.public.sharepoint.windowsservices)
  • 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: Restoring individual Files from Share point.
    ... > all documents are stored inside the sharepoint WSS database. ... > SQL or MSDE to maintain your WSS site? ... I dont want to restore all of the database. ...
    (microsoft.public.windows.server.sbs)
  • Re: SQL database
    ... You need to set the old content database status to "offline" first before SharePoint starts creating the new site collections in the new content database. ... "Daniel Bugday" wrote in message ...
    (microsoft.public.sharepoint.windowsservices)

Loading