Link to home
Start Free TrialLog in
Avatar of pkelley47
pkelley47

asked on

Dcpromo to SharePoint Server. Now Sharepoint will not start.

An internal server under my department was promoted to a domain controller.  This server was running SharePoint.  Upon reboot, SharePoint will not start.  I can access all database information but the application will not start.  The following error is given "Server Application Unavailable".
Avatar of alimu
alimu
Flag of Australia image

There's a knowledge base article about a doing a dcpromo after the sharepoint installation was completed. The dcpromo changes the rights of the Network Service group to the Temporary ASP.NET files folder and breaks Sharepoint.
Can you take a look at it and let me know if it resolves your issue: http://support.microsoft.com/?kbid=823379
Avatar of TTU_LAW_IT
TTU_LAW_IT

I'm guessing this is a test system?  Not to be a nag, but running MOSS on a production DC may be inviting some serious issues:

http://msmvps.com/blogs/OBTS/archive/2005/02/23/36785.aspx

If this is production, and you want to separate MOSS from the DC, you could bring up another MOSS install, then attach it to the current MOSS database and you won't skip a beat.  Reply back and I'll post a how-to.
Avatar of pkelley47

ASKER

Actually, the server was an absolutely disaster in more than one area and it could not be trusted.  I have taken a clean server and installed a clean version of SharePoint 3.0.  My issue now is restoring my database to the installation and it is kicking my ass.

I can attach the database in SQL Studio but attempting to attaching through SharePoint is issuing a "time-out" error.  I have attempted to mount through command line but unsuccessful.  

This new server is dedicated to host this and only this (save 2 printers).  It is production and I am starting to feel the water boil.

All help greatly appreciated.
PKelley:

Crud, db attaches can be fun.
Ok, how big is the db you are trying to attach? Is the timeout with the CentralAdmin GUI?
What sort of errors are you getting with stsadm?

What I have run into, and this may apply here, is the db has a GUID and attaching it to the same MOSS install, well, MOSS doesn't like that:
http://blog.henryong.com/2007/05/31/moss-2007-backuprestore-quirks-and-site-migration/

Let me dig around, I think there's a way to change the GUID.  Here it is:
https://www.experts-exchange.com/questions/24920320/stsadm-exe-o-addcontentdb-successfully-but-current-number-of-site-0.html?cid=1578

Also, when you are logged in, is it as the MOSS admin account/service account?

http://patrikluca.blogspot.com/2008/05/restore-subsite-parent-web-does-not.html
Ah, if the db is less than 25GB, we should be able to attach this with the CentralAdmin.

1a. give the MOSS service acct either dbadministrator or database creator privileges on your SQL system.

1. Login as the service account for MOSS on the MOSS server

2. Fire up CA on the server with the new MOSS install

3. Recreate your web applications.  

4.  When you get to the database name, put in a fake name such as MOSS_DeleteMe.  You will delete this database later.  

5.  Next step is to remove the temp database from each web application and attach the real database. To do this go to Central Administration -> Application Management -> Content Databases.  Select the web application you would like to change.  Select the database name (for example MOSSl_DeleteMe).   Check the box in the next screen to remove content database.  You should now see no database attached to the web application (it will also remove it off the sql server).  

6.  Select add a content database.  For the database name put the name in EXACTLY as you restored it which should be EXACTLY like it originally was.   Dont worry about the Search Server field since you have not started that service yet.  
The database is far less that 25 GB.  Actually closer to 200 meg, log file is 6 GB.  I followed you steps to the letter, but I am getting the message "Attaching this database requires upgrade, which could time out the browser session. You must use the STSADM command 'addcontentdb' to attach this database.

I attempted this yesterday and could not get the database to properly mount as SQLExpress will not start on this server and I am having to use PIPES to connect to Windows Internal Database.

I really appreciate your continued help on this.  I am on day 3 and it is nailing me pretty good.  
Pkelley:

Hmm, did you try the stsadm addcontentdb command?
Also, it appears you might have to recycle the IIS pools:
http://74.125.95.132/search?q=cache:KG807PXN8EcJ:www.eggheadcafe.com/aspnet/how-to/2811220/attaching-this-database-r.aspx+Attaching+this+database+requires+upgrade&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a

Oh, what version of SQL did this content db orginally run on? And what is the current type and version of SQL it's on?
With the SQL errors, you might need to go into the SQL Server Config Mgr and enable TCP\IP under the "SQL Server 2005 Network Configuration" listing.
I did try that and it said it was completed but I still feel I am missing something.  When it completes, there is no data populated. I know there is data in these tables as I could see it in SQL Manager, but it just will not come over properly.

After bringing many, many Exchange servers and their databases back to life, I am amazed at how much difficulty I am having with this.
 
This is what I am using for processing:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN>stsa
dm -o addcontentdb -url http://<servername> -databasename SharePoint_AdminConten
t_9b1969d0-7a54-4c47-be86-753fd992b383.mdf

Where I am getting this wrong?
ASKER CERTIFIED SOLUTION
Avatar of TTU_LAW_IT
TTU_LAW_IT

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
TTU,

The resolution was a bit frustrating.  I had found that the content database for SharePoint was unlike all of the other SharePoint databases and did not actually have SharePoint_ leading the name.  The content database was actually WSS_Content.  

I had performed every idea you sent and all failed but not due to you great advice, but actually to my assumption that if Microsoft would name the other databases SharePoint_ that logic says the content database would follow the same schema.  

Thanks for all of you help and constant assistant.  I will look for questions of yours in the future in hopes that I might repay your time.

Thanks again!
TTU was extremely helpful and certainly an expert.
PK:

Ah, OK, I wondered about that name, I figured you were using it for a reason, shoot, I should've asked if you had a WSS_Content db just to be sure.  I'm really glad you got things worked out.

I've had to migrate and re-attach a bunch, and there's always some new issue with SharePoint it seems.  Anyway, keep that 25GB db size issue in mind, once WSS_Content hits that, stsadm will be the only way to attach it if you have to recover it or use a copy of it on a test system.  
Not a big deal, the stsadm commands above are what you can use, it's just that if you try to restore from the GUI, CAdmin doesn't say 'hey, this db is too big, why doncha use stsadm?'  SharePoint can be a real heartbreaker that way!