• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1029
  • Last Modified:

SharePoint 2007 Central Admin not rendering after database move, so can't set the configuration database server. What to do?!

What i read to remove and copy and attach the ssee databases to sql 2005 seemed simple enough. I wanted to move to sql2005 away from SSEE before adding another WFE, moving the db's to SQL2008. But after removing all the content db's using central administration, including the admincontent db, central admin could not be found in order to 'remove wss from virtual server'. In a browser the page is rendered as 404; webpage not found, althouth the CA webservice is still running. So i continued on and attached all 5 db's in SQL server manager. That went fine. But now i'm supposed to 'connect to the restored configuration db' using Central Administration, but as noted it's not showing in the browser. Any ideas where i went wrong and how to make it right?
0
MMarlin7
Asked:
MMarlin7
  • 7
  • 5
6 Solutions
 
66866Commented:
Here are some things you want to remember when doing any Sharepoint migration
1. Always backup your farm using the built in Sharepoint backup tool
2. Using the Sharepoint Technologies Wizard, remove the WFE from the farm.
3. Using the same wizard, create a new farm (with the new database server)
4. Restore the farm from the backup created in step 1.

Just removing the databases when the farm is running will obviously not work.
Assuming your content database has been migrated properly, what you can do is
1. Run the Sharepoint Technologies Wizard, to build a new farm (specify the new database server).
2. Create a Web application.
3. Make the web application point to the content database that you had migrated from the previous instance either using the Sharepoint GUI or the STSADM addcontentdb command

0
 
MMarlin7Author Commented:
Ok, we'll see how the latter steps workout. I was already at step 2 by last night. Can you say even if it's possible to move the sharedservicescontent or the sp_admincontent db's?
Also, when i point to the migrated wss_content db, what can i expect; will all sharepoint groups and permissions be there? will page layouts and webparts be intact? is it to be expected that datasources will be present as they were? I guess i'm asking: ***What needs to be done outside of reconnecting the wss_content db so as to have the site operating again? ***What's the difference in what the content vs config databases hold?***
0
 
Ted BouskillSenior Software DeveloperCommented:
The only content databases you can safely move are NON Administration sharepoint databases.  Sharepoint is VERY sensitive to changes to the administration without using stsadm.  Moving the core configuration database is not possible without damaging Sharepoint.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
MMarlin7Author Commented:
I never tried to move any config databases, just ALL the content databases, including hte admincontent db. Sure wish the documentation spelled it out, as it does with so many other warnings, some fairly trivial.
So i reinstalled MOSS2007, will create a new site collection/web app, and replace the default wss_content db using CAdmin.
Can you answer any of my questions about the diffs in databases and the prep needed in CAdmin for a smooth replacement of the WSS_Content db?
0
 
Ted BouskillSenior Software DeveloperCommented:
The process to restore the non-Administration databases is fairly simple.

1) Create a web application and use a name like 'Temp...' for the content database (it will be deleted soon)
2) Using SQL server restore a backup or reattach the orginal content database for the web application
3) Using 'Central Administration' attach the newly restored database to the web application
4) Using 'Central Administration' delete the content database name 'Temp...'

NOTE: Restoring the original content database on a new blank one added to a new web application will NOT work
0
 
MMarlin7Author Commented:
Thanks for the reply - i'm about to jump off a cliff. So i keep hearing it's fairly simple. But the latest snag is getting reporting integration connected again in CA. (The web service asp.net account box sits empty and apppools entered in rs config don't stay after Apply, so the report url is page not found and i can't enter it in CAdmin.) I figure i need to have reporting and excel services running before connecting the content again? What prep do i need to make to make content attaching go smooth?
0
 
MMarlin7Author Commented:
I swear i'm going to need to have my head checked after this.
0
 
Ted BouskillSenior Software DeveloperCommented:
Activating the applications services first or last shouldn't matter when restoring the content databases.

Did you reinstall RS integration after you rebuilt Sharepoint?

We abandanded RS integration.  Performance wasn't great and the additional features weren't worth it.
0
 
MMarlin7Author Commented:
So i got the RS integration working again after reinstalling to a named instance, which gave me another website to work with in the ssrs config tool (i have a hunch there was some id conflict going on with office server web services web site being used for rs AND sharepoint, a conflict that wasn't going away) So now i can see the RS url, and settings in CA took fine.
Now, with a focus on the WSS_Content db that's now attached to SQL2005, that was in the Microsoft#SSEE directory on Friday and which i detached and reattached to SQL2005 and made some security changes to. I tried adding it via CA and get the 'unknown error/go back to site' screen. So now i'm hunting for the cause of that error.
Any insight or advice means a lot, and i'll give you all the points unless someone else chimes in with ideas - but I don't think anyone else is brave enough!
 
 
0
 
MMarlin7Author Commented:
Yeah, i'm doing this move to sql2005 to attempt improving performance. Reports take a long time to render; up to 30 seconds sometimes. But everyone likes the snazzy reports on the sharepoint site. And that's why i'm dea meat if i don't get the site back up, even with it's not-so-great response times.
0
 
Ted BouskillSenior Software DeveloperCommented:
The following two URLs give you everything you need to know about Sharepoint permissions

This one explains how to reset the service accounts, however, if you look at it the clues for service account permissions are there and what they affect
http://support.microsoft.com/kb/934838

This URL is for a DBA to setup the Sharepoint databases manually instead of using the wizard.  However, once again it helps understand what permissions are required by Sharepoint to access the different databases.
http://technet.microsoft.com/en-us/library/cc262869.aspx
0
 
MMarlin7Author Commented:
So the site's backup and running and **looks** the same. Other steps to finish the job after swapping the default and the original wss_content db were:
1.reinstalling some missing custom webparts,
2.configuration of shared services and excel settings,
3.moving reports out of the folder they were in to another folder and resetting pointer url's in pages using those report web parts, as well as reconfiguring dsn's. The original folder when opened via All Settings/All Site Content was throwing an error about a line in the reportserver web.config file, a line about the 'partitionResolverType'. I had to move the RS web service off ort 80, into a new website with different webapppool and then reconfigure using ssrs config and CAdmin/reporting integration.
NET RESULT: A ton of experience dealing with many errors and hangups, and a ***WSS_Content*** db running on SQL2005 rather than in Microsoft#SSEE. (Don't try moving the admincontent db, and i can't see how the sspcontent db might be reconnected in CAdmin, so i won't bother with that ever again either)
How do i give Tedbilly some points for his technical and morale support?!!
0
 
Ted BouskillSenior Software DeveloperCommented:
Another tip, make sure custom web parts are deployed using "Sharepoint Deployment Solutions" so they are included in backups.

You can split points between one of my answers and one of yours to close the question and give me some points.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 7
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now