This post is just so I can paste a URL instead of the same block of text again and again in the forums :) 

There's 2 purposes to finding the log files during/after a failed install:

1. Inspect them yourself to see if you can figure out how to fix the problem based on what was logged
2. Send them to others to have them help you (for instance, on the MSDN forum for TFS Setup, or emailing them, or whatever)

 The quick version of the "rules" for finding the right log files:

1. Look in both %temp% and %temp%\.. (the parent dir of %temp%).  It's a long story why that's the case, but it's still that way in Orcas (TFS 2008) as well.
2. Sort based on Date Modified descending so the files written to most recently are at the top
3. dd_install_vstf*.txt and vsmsi*.txt are the ones that will be most helpful in the 95% case, with dd_depcheck*.txt useful on those other occasions where we're having version number issues (this tends to affect us more internally than it does external customers)

Using my dev machine's explorer, here's a screen shot of the files from my test machine from an install I did Wednesday morning:

 Things to notice:

• the files aren't in my %temp% directory, but its parent dir (as mentioned before, this can happen)
• Since I sorted based on date modified descending, it's clear which files are from the install and which aren't (the bottom 2 in the list aren't, since they were from the day before)
• The 3 highlighted files (dd_install*.txt, vsmsi*.txt, dd_depcheck*.txt) would be the ones I would inspect if I had a problem during install.  You may think dd_error*.txt would also be useful, but it's actually just a subset of the lines in dd_install*.txt so the dd_install*.txt is more useful because you can get more context on what was going on when an error occurred.

One last bonus tip: if you have a problem during install (for instance, you get a dialog that pops up saying some operation failed and would you like to abort/retry/cancel), that's the point in time you'll want to go look at the log files. 

Why is that?  Because once you say Cancel and it starts to go through the "we're failing setup" process, there's lots of attempted rollback operations to undo everything that had been done successfully during the install.  Because of this, it's easier to look at the log files when the last thing in the log file is the failure that happened rather than having to scan up past all the rollback operations.  The relevant data is in there either way, just a little easier to tell what blew up the moment after it happens. :)