I just started digging sharepoint 2010. To get a clear picture of sharepoint environment my question is.

In my office I have given a single Quad core machine and being told to get expertise on sharepoint 2010. But I do have a seperate SQLServer machine(Reserved for UAT's) so its like two machines one for sharepoint and another for SQLServer.

What I am confused about is if I do development on the machine I have and use UAT sqlserver machine for repositories and once I will reach at the stage where I need to demonstrate and move it on production how would I do that. Cause production layer has a web application server where we have .NET applications running and production also has a seperate SQLServer and we cannot access production offcourse.

So do i need two machines for DEVELOPMENT and two machines for UAT and two for production?

So what strategy should I opt so later I won't have problem in development to UAT and then to production.


7 Answers 7


You don't necessarily require the same number of servers per environment but it does help to validate testing.

You could for example have a standalone (single server) machine for dev, 2 UAT server and 2 production servers - this isn't uncommon but you will need to ensure that you have sufficient hardware resources (SP2010 loves RAM and fast disks for example).

While Microsoft's Hardware and Software requirements documentation recommends 4GB RAM as a starting point I would suggest that your development server has 8GB of RAM to ensure adequate performance (you will likely need much more for production - check out Microsoft's performance and capacity planning docs).

It also sounds as though some reading around the SharePoint solutions framework would be beneficial - I would check out Microsoft Developer Training documentation. This is key to understanding how solutions are deployed to the various environments that you mention.

  • thanks for the answer. so it means i need to configure sharepoint enterprise 2010 and sqlserver 2008 on my development box and start my development. But once I will reach at the stage where i need to demonstrate my work then the same environment i need to build on UAT. if yes then how would I deploy the changes on UAT? this is what i am fail to understand. how this sync thing work in between two identical but isolated environments.
    – user239684
    Apr 20, 2011 at 4:54
  • For development it's efficient effective and Apr 23, 2011 at 17:48

You must deploy your WSP solution between each staging. This is done by uploading your WSP file in Central administration of your UAT, Prod environment. So it means you need to install SharePoint 2010 on each environment. I don't know if you understand this detail.

Do you need more details ?

  • thanks for the explanation. Well understand that i need to install sharepoint 2010 on each environment. There are two kind of developments...One is Out of the box (whatever sharePoint 2010 offers list, document libarary etc) and 2nd customized using Visual Studio like web parts and other stuff....so far what i understand from ur answer is WSP build but its for customization agreed. what about out of the box?? how to move out of the box stuff to staging or production?
    – user239684
    Apr 20, 2011 at 12:16

There is quite a bit of documentation on this from MSFT.

A good place to start is here: http://msdn.microsoft.com/en-us/library/gg604045.aspx


We are trying to achieve what is explained here. Having a TFS + Build Server + Testing environment all working together is a must, but somehow complex to achieve.


The environment I work on is a bit simpler...somewhat. Every machine is a VM

  • Development works locally on single machines, all on VM's. This allows coding and installing updated WSP's though Visual Studio
  • Integration compiles the builds and deploys to the general Development environment, still single machine
  • Test is a multi-machine environment with a CA, WFE, database and Query Server is the first Farm so we can test in a close to Production environment
  • Production is also a multi-machine environment with a CA, 2-WFE's, database, Query and Crawl Server

You could probably do smaller, depending on the Users you expect...


Generally I insist that Test and Production Environments match To The Letter but if resources don't permit I may allow the following slips:

1) Test SharePoint Installs can use a shared instance of SQL Server While a production gets its own instance, but after discovering a bug with Named Instances in SharePoint 2010 I'm reluctant to even do this

2) I may allow only one WFE if we're not testing custom applications; if more than 1 are installed in production (but if there's custom .NET coding, nyuh-uh)

3) If apps run separate from the WFE's, I tend to allow fewer app servers on test than production but not allowing apps and web front ends to be the same

4) I like to make sure test and production are in the same active directory domain, but may permit otherwise as long as all SharePoint related accounts are configured the same however the security model between test and production must be the same, if we're using Kerberos Active Directory in Test, we use Kerberos Active Directory in production

Development boxes I tend to be very liberal with. There are never any resources for those.


For development it's a good idea both from a cost and ease-of-use stand-point to use 64-bit Windows 7 machines. You probably already use a 64-Bit W7 laptop for everyday use, just use that.

For UAT I recommend using single server Hyper-V instances so you can allocate resources additional resources during UAT. I always have a support instance a production replica for trouble shooting, content recovery etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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