Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

We currently are looking to build out a single farm MOSS 2007 instance. We took an image of the production instance, along with SQL server, and built the dev instance off of this.

The issue is this defeats the purpose of a dedicated dev instance because everything points to the prod instance. Question is, hhat is the best approach to reconfigure the instance as new dev environment? Can I delete the config_DB and re-run the Product and Techonology wizard? I am not worried about the content as I will just take a backup of the prod content database and import to the dev instance.

Failed to mention if it is more advisable to just reinstall MOSS 2007 and create all the new SharePoint DB's from scratch.

share|improve this question
    
Possible duplicate of: sharepoint.stackexchange.com/q/24836/3661 –  shufler Dec 14 '11 at 20:38

2 Answers 2

After a little research I was able to get comfortable with the approach of running the configuration wizard and dropping the configuration from the current farm and configuring the instance to point to its own farm. I had some issues a long the way such as removing the associated config databases and specifying a new config database when I ran the wizard.

share|improve this answer

SharePoint doesn't support imaging (cloning) as a method for copying a farm.

The supported approach is to create the new farm and restore the data from either a SharePoint backup for the farm data and content or a SQL database backup (and SharePoint attach) for the content.

In SharePoint v3 (WSS 3.0, MOSS 2007) restoring the configuration database is not supported. The reason it is not supported (especially in a cloning scenario) is that there are references within the config database to the old farm (server names is a big one). Since directly modifying SharePoint databases is completely unsupported you can't restore the old database and change the values.

A lot of people get hung up on this and want to restore the configuration database because they think it has configurations they need when these configurations are likely in the content databases. The data within the config database is specific to one farm and only one farm. If you create a new farm, it has it own configuration database so there is no need to restore an old configuration database.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.