Restore or Create a new SharePoint 2007 MOSS farm with only backups of databases.

We had a MOSS SharePoint 2007 development farm made up of 2 servers, the SharePoint server and the SQL Server 2005 server. Some users were using this as a production server with irreplacable content and intranet sites.  There was a castrophic failure on the SharePoint server and there is no backup of the SharePoint farm.  All we have are the databases on the SQL server. Is there a way to restore or build a new farm using these databases or at least a way to restore the content (sites, documents, etc.) to new Web Apps and Shared Service?  I have tried building a new farm with a SharePoint reinstall and new Central Admin and attempting to add the content databases via the CA GUI and through cmd using PSConfig and Stsadm, but have not been successful.  Thanks,
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I'd recommend if the data is important for you contact a Microsoft certified partner specialised in sharepoint disaster recovery. The sooner you do so, the more chances you'll have in recovering more of your system.
Build out your new Farm. Create the Web App, which will require your to create a content db. Name this contentdb, "dummy_contentdb".

Restore your production contentdb.

Go to CA->Application Management->Content databases. Select your web application and then select "Add a content database" Select your production contentdb.

The content db has all the sites and documents.

Khurram Ullah KhanCommented:
what error you are getting when adding the content DBs? make sure you have the same service pack and patch level as you have before this failure for front end.
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

RussRamsAuthor Commented:
I tried the restoration to SQL and the new web app build and then "add a content database" in the CA GUI once more for good measure and have also tried doiing the addcontentdb using stsadm and no matter how I slice it, I get the following error: "ProductionContentDB on MSSQLServer contains user-defined schema.  Databases must be empty before they can be used.  Delete all of the tables, stored procedures and other objects or use a different database."  I have tried researching a way to change the schema or extracting the DB contents to a new database, but have not found a solution.  Any ideas?
Maybe you ContentDB backup isn't good or does your contentdb contain "user defined schema" (custom tables, maybe a third party app/tool)? Also double check the servicepack/patch level as khurramullah suggested.

I've used the GUI to attach production a contentdb to my non-production environment before.

I would suggest you rule out the content db attachment process by using a known good contentdb with maybe one site. Once you confirm you are about to attach a test contentdb and the site comes up, you can move on to figuring out the issue with your production contentdb.

RussRamsAuthor Commented:
Would this issue and schema error be caused by the fact that the original SQL Server was 64-bit and the new SharePoint system I am moving the content db's to is using 32-bit SQL Server?  They both are using version 9.00.4053.00 and SP3 Enterprise releases.
No, I do not believe its related to 64-bit or 32-bit SQL. The DB schema would be the same.

Assuming you don't have any third party or custom schema changes, I will place my bet on the a mismatched patch/service pack level of your SharePoint Server.

Restore your old ConfigDB and check the Versions table. Verify that the SP Version is the same between your old ConfigDB and your new one.

Use this article to figure out what patches need to be installed to get to the right version -

RussRamsAuthor Commented:
I was really hoping you were correct, quihong, but the versions are identical according to the version table in the 2 separate config databases.  To my knowledge, there has not been any custom tables created or third-party SharePoint utilities used on any of what were the existing sites.  I may be at my last resort and have to extract the files out of hte content databases and rebuild all the sites, <sigh>

Check this thread out -

Had the same issue as you, ended up using another server and it worked.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
RussRamsAuthor Commented:
I had to reinstall the SharePoint server 2007 from the original version we started with and then install the service packs and updates one at a time and tried to add the content DB with each step and finally it uploaded successfully after one update past Service Pack 2, but only using STSADM -addcontentdb. So, thanks quihong!
So it did have something to do with the patch version? Strange that the version number matched in the configdbs.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SharePoint

From novice to tech pro — start learning today.