Build a SharePoint 2010 Test/Development Farm

In this post I am going to step through my process of spinning up a test/development SharePoint farm. In this scenario I decided to combine the testing and development on one farm. This will be a copy of the production farm on its own separate domain. I know there are posts on this out there already on this process but I decided to post about this anyway as I found some of the other posts hard to follow. With this post I want to spell out my own steps for my specific scenario in a clear concise format and hopefully this will help someone else at some point.

The first thing that needs to be done is build the test/development domain and the servers that will be used in the new farm. Here is a list of what I would put in the test/development domain:

• Domain Controller
• DNS
• Exchange Server
• SQL Server
• SharePoint servers (Web Front End Servers and any Application Servers you need.)

The Exchange server is not required. I wanted one in my test/development environment for some email testing. The production SharePoint farm consisted of 7 servers in but I went with 4 servers in the test/development environment. You do have the option to scale back on the amount of servers in the test/development farm and have a solid environment for development and testing. Ok. I will jump right into the steps now.

Deploy test/development SharePoint farm

I used a couple of tools to speed up this process. The first tool is called SPDocKit. (Thanks Sean Mcdonough for telling me about this.) I used SPDockit to go through and document every little detail of the production environment so that I knew what I was dealing with. This gave me a list of all web applications, site collections, the content databases that were being used, all services and service applications being used in the farm, any 3rd party solutions that were deployed as well as other any other data I wanted to know about such as email configurations.

I was able to take this data and create a plan for the test/development farm to ensure it matched the production farm as close as possible even with the amount of servers scaled back.

SPDockit can be found here: http://www.spdockit.com

The second tool that I used is the SPAutoInstaller. SPAutoinstaller is a tool that can be used to install and configure a SharePoint farm via scripts. It is easy to use and works well. This saves you time because you simply go and build out the script and input the configurations you need. Once you run the script it will completely build the farm for you. Now for me in this particular scenario I let the SPAutoInstaller do everything except for the site collections. I needed all the site collections that came over to be placed in their own content databases. That is why I skipped creation of the site collections within the script. These have to be restored in SQL as you will see later on in this post. I did however let the script create the web applications and all the managed paths that I needed.

The SPAutoInstaller can be found here: http://autospinstaller.codeplex.com and a great tutorial for the SPAutoInstaller can also be found here: http://www.wahidsaleemi.com/2011/11/autospinstaller-getting-prepared.

Please note that you need to go and deploy and custom solutions or any 3rd party solutions to your test/development farm. Now that we have the new environment spun up. Let’s move on to copying our site collections over from the production farm to the test/development farm.

Copy production site collections over to test/development farm

So my method here is that we built a replica farm over in a separate domain for test/development. We let the script tool create the farm along with service applications, web applications and the managed paths. We did not create the site collections and here is why.

#1 in my scenario these need to each have their own content database and #2 these are what we will be brining over and they will contain all the data we need including any custom master page and CSS. Permissions will also come over with the site collections but they will not work as we are in a new domain. You will need to either use a 3rd party tool to copy over permissions across domains or use the permissions that come over as a guide to re-assign permissions to the same users in the new domain (you will need to create the AD accounts for them). Here are the steps for copying the site collections over:

• On your production environment get a backup of all of your site collection databases. The format you want these to be in is .bak. For example: SiteCollection1_Content.back.
• On the SQL instance for your test/development farm restore your site collection databases. So you need to restore the SiteCollection1_Content.back you made. Here are some screenshots detailing the steps:

• Open SQL management Studio>right click on Databases and chose Restore Database.

• On the general property page give your database a name. This will be the name it has once it is restored. Select the database you will be restoring from.

NOTE: If you want this is a good time to rename the database. I added a Test_ in front of all of the databases that will live in the test/development environment. The new name looks like this: Test_SiteCollection1_Content.

• Click on the Options property page. Select Overwrite the existing database. click on Click ok when done to start the restore process.

• Give permissions on the restored database to the SharePoint farm account that lives in the test/development environment. When you restore the site collection database it does not know it has been moved to a new farm therefore it does not know about the test/development farm administrator account. If you do not add the permission and you go to add this to SharePoint you will see the following error:

Here are the steps I take to give permission to the farm account on those databases in SQL Management Studio is expand Security>Logins. Find your farm account and chose properties. Go to User Mapping. Find the databases you restored in the list select it and check db_owner permissions. Click ok when done.

NOTE: You can give permission on the databases directly but doing it this was allows you to give permissions on multiple databases at the same time. This is helpful when a large amount of databases are involved.

• The final step is to add the content databases we restored to SQL in SharePoint. Doing this will bring in those site collections under the managed paths they had before but with the test/development environments URL. To do this:
  • Open Central Admin
  • Click on Manage Content Databases
  • Click Add a content database
  • On this screen select your web application, input your SQL Database Server and the Database name. Click OK.

And as long as there are no errors your site collection should attach to the managed path and should come up just fine.

Now you can begin working with your test/development farm and it will contain the same data that you have in production.

Keeping your test/development farm refreshed

So these question always come up in regards to test/development farms "How do I keep a fresh copy of my production farm on my test or development farm?, How do I automated updating my test/development farm?" and the answer is almost always the same "There is no real good automated solution. The best thing to do is use backup and restores :-)". Now there are other methods such as content deployment paths and such but this does not meet every administrator/environments needs. Here are some of these other methods:

• If it’s just moving a SharePoint solution, deploy the solution to the test/development environment (Typically a .wsp package).
• For managing development that happens in the test/development farm look at Microsoft Team Foundation Server (TFS) or similar source control tool. This would help to move changes done on test/development farm to the production farm after being tested without duplicating development efforts on the production farm.
• SharePoint backup/restore
  • Backup and restore configuration database to get Farm level settings.
  • Backup and restore service application databases.
• SQL Database Attach (only allows you to restore/update an entire content database)
• SharePoint Content Deployment Paths (Content deployment is used to deploy content from one site collection into another site collection. The source and destination site collections can be in the same farm or in different farms. Content deployment is a one-way process.)

Here is the method I like to follow:

• Transfer a one-time copy of production farm onto test/development farm.
• Use a source control tool such as Team Foundation Server to manage pushing any development changes from the development farm to the production farm this would cover solutions, CSS etc.
• At a regular interval copy the production farm over to the test/development farm for a test/development environment refresh (Such as the method from this post). An example would be to do this once every 3 or 6 months. The following diagram gives a visual of this method:

There are many ways to spin up a test/development farm and keep this up to date. I would be interested in any feedback on what you do for these. Feel free to share in the comments.