When clients request a test environment as an “after thought” to installing and configuring a production environment you’ve got to make a few decisions about how this will be done. This post will outline how I prefer to swing it and what has worked for me so far. Keep in mind though that farm size and capacity should dictate your methods. The methods I discuss here fit for a small to medium size farm.
Where possible recommend setting up virtual servers to replicate the production environment. This is usually a lot cheaper and allows for a lot more flexibility. You quite often see businesses using a test environment which is a single server setup despite their production farms containing multiple servers. It is always best to try to mimic the environment completely and with virtual servers this is a bit easier as you can magically conjure a swish new server from virtually nothing 😉
Snapshot or fresh install
Fresh install definitely, although I can’t say I’ve ever tried the alternative. If the prod environment happens to be virtual too I wouldn’t recommend taking a snapshot and restoring it as a test environment. I can imagine all kinds of conflicts and issues with that and you reeeeally don’t want to jeopardize your production environment. I prefer to start from scratch and install the pre-requisites, SharePoint, services packs and updates again.
Database Servers- to share or not to share
I usually recommend sharing (remember I am talking about small to medium farms here) but that’s usually because it’s the more preferred, cheaper option. If you already have a spare SQL server sitting around, you can certainly take advantage of that. I do find it a bit of an advantage sharing with production though when it comes to troubleshooting issues. Remember we really want prod and test to be identical. When an error is occurring on the prod environment and it is also occurring on the test server you can pretty much assume the issue is occurring in a shared resource which narrows down the search somewhat. I always recommend creating a separate SQL instance for test though. That way you can keep you DB naming convention the same and it’s not confusing when trying to figure out which DBs are for prod and which are for test.
Set your SSP and services up as you did in production although it doesn’t really matter if this is exactly the same. For example the user profile import probably doesn’t need to run quite as regularly as it does in production but then again I have been pushing the identical environment thing so you may just want to make the effort and set them up with exactly the same schedules. If you have created an “as built/installed” document previously with all this configuration detail, now is a great time to test is accuracy.
Content Database Migration
Now as you have installed SharePoint in the exact same way as in production (with all the latest updates and service packs) you can relax and know that you can add your production content databases to the test farm no problems at all. What I have found works best is to create the root web application, let’s say SharePoint-80 , in the test system and if you want, create a site collection and navigate to it to make sure all your install efforts have not been in vain and everything is working. Then backup and restore your production root web app content DB to the test instance and overwrite the root site DB with the same name. Once you’ve done this you can add the content database through the Central Admin GUI. That should be that, you should now be able to navigate to the root site and there should be all your production data. Migrate any other content databases as needed and add through GUI.
Now this part will depend on the type of customisation you have gotten your hands dirty with. If SharePoint designer is your friend and most of your customisations have been through designer you should make pretty short work of it. These customisations will be stored in the content databases you have already migrated. Any custom web parts or features used in production will have to be migrated into the test file system (GAC/bin/hive directory). You also have to install and activate any features you whack in the hive – just because they are in there doesn’t mean the job is done. If you have wrapped up all your customisations in lovely little solutions that you must now set to work deploying those (well done SharePoint nerd). If you have been a good developer you won’t come across any nasty dependencies which dictate in which order you deploy your solutions. Lastly, if you are a bit naughty sometimes and make changes to files in the hive directory (like blog site templates etc) then you need to make sure those files have been migrated from production too. I tend to apply these customisations across all SharePoint servers in the farm even if they are not WFEs. That way, if you ever need to swap one in for a sick WFE, its easy peazy.