How many build scripts do you need?  There seems to be some massive confusion around TFS Build Scripts, namely, how many a single project needs.  If your answer is one, you too have a misunderstanding!    In my experience, one build script is not nearly enough, in fact, I encourage several.  Here's the why and how.

Why:  Visual Studio Team System (VSTS) and Team Foundation Server (TFS) is absolutely brilliant at tracking information related to a series of builds.  That information is archived, analyzed and reported in a very useful fashion.  BUT, it it reported by the NAME of the build.  Thus, if you only have one build type, you can only have one set of reports!  And that's no good!  You need more. The primary reason for having more than one build type is to get good, easily understandable, accurate metrics.

1. First, you need a build script for your continuous integration builds.  This script runs every time someone checks in code (with certain restrictions).  You likely won't want an aggregate report on these builds, except for rare cases -- there are just too many of them.  This build is optional.  I'm a fan of CI, but if it's a bridge too far, don't worry.  The critical build is the nightly build...
   
2. A TFS Build for your daily / nightly builds.  This build runs every night at a set time.  This build shows you what was accomplished during that entire day, including quality metrics, code churn, etc.  This is one of the most valuable builds, since its reporting is clearly segmented by time -- one build per day.  This allows a team to see what is being accomplished on a day to day basis.
3. A TFS Build for weekly builds.  This runs every weekend.  Like the daily build, it will allow the reporting engine to show you what was accomplished that week, and how quality changes from week to week.  This allows you to see aggregate changes over a chunkier time sequence, namely weeks. 
   
4. An end-of-iteration build.  I've found you don't need to go any longer than weeks this for most projects, as far as reporting is concerned.  However, you may choose to create a build that runs at the end of every iteration.  This gives you metrics on what was accomplished during the entire iteration.
5. An on-demand build.  This one is used for folks who just need to trigger a build whenever.  Unless it's necessary or useful, you may choose to have this build not report anything back to the data warehouse.

How:  It's easy!  The reason for all these builds was stricktly for the reporting.  That means that each of these builds is likely going to be nearly identical!  So, all you need to do is create the first build (the hard part), and copy it several times, giving it a different name each time.  That's all there is to it! 

So, go forth and replicate those builds!