- Domain Controller
- Exchange Server
- SQL Server
- SharePoint servers (Web Front End Servers and any Application Servers you need.)
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:
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...