Question: I did a lot of research on this subject but couldn't find any end to end solution to implement the "build once and deploy many" using TFS 2010.

Basically what I am thinking of is having a build definition that will build a solution with multiple projects to be deployed (web application + database project + web service + reports), place the output in the drop folder and from there based on quality and version manually decide to deploy all the projects onto various environments (qa, ua, staging, production).

I know that I can modify the build process template to deploy multiple projects right after the build, something like "Build Main And Deploy to QA", "Build Main and Deploy to UA" etc, based probably on changeset# or labels but this means building every time.
What I would like is more like a dashboard that will allow the deployment team to deploy the exact build that was tested in QA, on UA environment and after getting the green light to deploy it on production. Of course that means the configurations files should be updated accordingly at the deployment time.

I am also considering defining some build definitions that won't actually build anything, instead it will deploy an existing build (based on version) to a specific environment, but it looks a bit strange to say the least.

Answer: 
I know this is a late response, but things have changed since 2012. Microsoft has a [Release Management offering](http://www.visualstudio.com/en-us/explore/release-management-vs.aspx) now that is designed from the ground up to enable "build once, deploy many". Modifying build process templates is always a pain.
Daniel's answer is pretty much the standard way of getting a build system like TeamBuild to handle deployments. It feels a little weird because you are bending a tool to another purpose. It can definitely work though. 

The other approach is to get a pure deployment tool that integrates with TFS / TeamBuild. The deployment across environments would be natural, but then you have two tools to manage.