Just some links, but interesting reads: Talk about performance, implementation, etc.

An Extensive Examination of Data Structures Using C# 2.0
Part 1: An Introduction to Data Structures
http://msdn.microsoft.com/library/en-us/dnvs05/html/datastructures20_1.asp

Part 2: The Queue, Stack, and Hashtable
http://msdn.microsoft.com/library/en-us/dnvs05/html/datastructures20_2.asp

Part 3: Binary Trees and BSTshttp://msdn.microsoft.com/library/en-us/dnvs05/html/datastructures20_3.aspPart 4: Building a Better Binary Search Tree
http://msdn.microsoft.com/library/en-us/dnvs05/html/datastructures20_4.asp

Part 5: From Trees to Graphs
http://msdn.microsoft.com/library/en-us/dnvs05/html/datastructures20_5.asp

Part 6: Efficiently Representing Sets
http://msdn.microsoft.com/library/en-us/dnvs05/html/datastructures20_6.asp

I promised to get back to the question of security in Team Foundation Server, so here we go...

My main problem was that the only way everything was working out of the box was with the TFSSetup user as admin on both boxes. I wanted to scale this back and only give appropriate permissions to the roles.

The best way to start this was to remove this user from the admin roles after everything was working, and then see what broke.

The first issue was the identity of the application pool "VSTF AppPool". Any app pool identity must have access to the temporary asp.net folder in the framework folder under system root, and to the windows temp folder under the system root. I added the identity to the STS_WPG group and gave that group modify permissions on these folders. That made it possible for the app pool to run.

I also had this identity running the TFSServerScheduler service. This of course requires to the 'run as a service' user right in the local policy.

Finally on the application box, I put this identity in the administrator role for the sharepoint services site on the box which will control the Team Server content. Maybe this could be pared down as well, but my main goal for now was to take away box-level permissions.

On the data box, the same domain user referenced on the application box runs the app pool for the reporting services. Again, this user needs access to the same temp folders referenced above. <mini-rant>This is part of why I don't like having to install IIS on the data box - more config that I already did somewhere else. If I bother setting up an IIS box, I shouldn't have to do that everywhere. So, I do hope this limitation on reporting is based on a beta setup, not some full requirement of the solution.</mini-rant>

This done, it was immediately obvious that database permissions would now be required for the user running the app pool. I added the identity to the local 'TFSReportUsers' group, and then gave this group database access in the 'public' role to "BisDB", "BisDWDB", and "CurrituckDB", "VSTEAMSCC", "VSTEAMSCCAdmin", and "VSTEAMTeamBuild".

I gave dbo role access to all of the above databases to another user account which was used as the identity of the "SQL Browser", "Report Server", and "Analysis Server" services.

Finally, I created a domain group for all the users utilizing the team system. I then made this group a member of the "TFSReportUsers" group on the data server. This group has report using permission on the reporting services website. I also made this group admin on the Team Services sharepoint site.

I think that did it for basic functionality. As far as team foundation server itself, you have to give permissions to users and groups there as well. This i did by giving my 'TFSDevelopers' domain group broad permissions in the TF roles.