Sharepoint 2007 copy production farm to test

Hi,

two new servers, one db and one sharepoint
I have seen 101 articles on this but nothing definitive. I'm looking for a step by step procedure which will let me take a copy of my production environment and and restore it to my two new servers as my test environment.
can any one help, do i use stsadm, a step by step guide please, many thanks
thclipper1Asked:
Who is Participating?
 
ambot13Connect With a Mentor Commented:
1. Document your existing installation. Record such items as:

    * third-party web parts
    * specialized DLLs – make sure there is a version compiled for 64-bit OS
    * templates (stsadm -o enumtemplates)
    * packages (stsadm -o enumsolutions)
    * presence of static paths
    * which web applications are linked to which databases

2. Prepare the existing Windows 2003 server:
Make sure it is at least upgraded to MOSS SP1. If possible, update it to the latest cumulative update. http://technet.microsoft.com/en-us/library/cc263467.aspx
The Sharepoint installer account will need to be a local administrator on the SQL server, and you will need to log into the SharePoint server as that account during the installation process.
3. Prepare the new Windows 2003 sever:
a. Use these instructions to install MOSS 2007 on the new server: http://technet.microsoft.com/en-us/library/cc287960.aspx
b. Add any web parts or other specialized components recorded in Step 1.
c. Configure the permissions.
d. Configure the SSP. It is theoretically possible to migrate an SSP, but I found the procedure to be more trouble than comparing the two side-by-side and replicating the setttings.
4. Perform a test site migration:
here are the specialized instructions for moving between AD domains.  See the first comment: http://www.tonstegeman.com/Blog/Lists/Posts/Post.aspx?List=70640fe5-28d9-464f-b1c9-91e07c8f7e47&ID=20
a. Make a SQL backup of the content database.
b. Create a blank database with a new database name.
c. Restore the backup into the new database.
d. Create a web application on the new server, and specify the new database name during the creation process.
e. Check the site collection administrators to make sure you are there.
f. If required, do an IIS reset (”iisreset /noforce” at the command line).
g. If using a host header for the site (intranet.company.com), create a DNS entry pointing to the new server with a test site name (intranettest.company.com).
5. After testing of the migration is complete, perform the production migration:
a. Notify users that there will be some downtime.
b. Check that no timer jobs are running.
c. Quiesce the farm for five minutes.
d. Run the preparetomove command for your content database.
e. Make a SQL backup of the content database.
f. Restore the SQL backup over the top of the test database for the new farm.
g. In Central Administration, remove and re-add the content database to the web application.
h. IIS reset.
i. Test internal and external (if applicable) access to the site. Also do some functionality checks: alerts, search (after a full crawl), navigation (static links). Check the Windows event logs for errors.
6. Cleanup:
a. Remove the web application and IIS site from the original farm.
b. Remove the SharePoint installer account from the local administrators on the SQL server.
c. Remove the DNS entry for the testing site.
7. Back up your new environment as soon as it is in a satisfactory state.

0
 
quihongCommented:
No one is going to be able to provide you a step by step guide since every SP environment is different (custom application/web parts/features/etc).

Creating and maintaining a SP Test environment that matches your production environment can be complex and very tedious to maintain.

What exactly do you want to "test" or what do you really care about matching up?

0
 
thclipper1Author Commented:
I will be migrating everything to two new servers, but obviously want to test everything on the two new servers first before switching off the current live environment.,
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
quihongCommented:
So you are not really building out a test environment, you want to migrate your env to two new servers (new hardware, different domain)?

You should treat it as a Disaster Recovery scenario then.
0
 
thclipper1Author Commented:
Corrent, it will be a migration.
It is a different domain also yes, with new hardware
0
 
quihongCommented:
That's a very complex scenario. I'm going to step back and let someone else give it a try.
0
 
ambot13Commented:
I did a gradual cutover while also upgrading to Windows 2008 64-bit (great idea, by the way).  Here is how I did it: http://www.prostructure.com/blog/2009/08/14/gradual-migration-of-a-moss-2007-farm-from-32-bit-windows-2003-to-64-bit-windows-2008/.

0
 
thclipper1Author Commented:
Any further details on this by any chance.
surely it can't be that difficult, it's just an app and a db :-(
0
 
ambot13Commented:
What OS are you migrating from and to.  If you provide more details, I can customize my step by step list for your instance.
0
 
thclipper1Author Commented:
Hi Ambot,

Both OS's are Windows 2003 so no change in the OS.

So it's literally just two new machines in a different location that I'm migrating to.
While I'm migrating, I don't want any downtime if possible on the current live environment.

Thanks
0
 
thclipper1Author Commented:
FINALLY, THANK YOU!!!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.