Do it right the first time! 🙂
There’s quite a few posts on Team Foundation Server 2010 (TFS) and how to install and configure it, as well as a really good CHM file from Microsoft on the same topics, so I won’t go through duplicating what everyone else has done and will link to one at the bottom of this post. I’m writing this just to relay the experience I had with getting the product configured just the way I wanted it, or some facsimile thereof and some lessons learned.
After viewing some videos on YouTube of TFS, reading some of the Microsoft marketing material, and some of the posts on it, I decided to stand up TFS in my environment to see how well it works and to explore changes since the last version. Right now, the team I lead isn’t really using any ‘set’ collaborative product. We tend to work in small teams on projects so the need isn’t really there, though I’m sure the organization wouldn’t hurt. We’re currently using Subversion as our source repository and occasionally use MOSS or WSS to collaborate. Otherwise it’s phone calls and emails since we also tend to bounce around the country. Enough background, on to TFS installation…
After reading through a few blog posts and Microsoft’s documentation on how to install and configure TFS, I stood up a Windows Server 2008 R2 VM and installed SQL Server 2008. I was going with a single server install. I followed the documentation to the letter for a single server install, and everything worked out just fine. WONDERFUL! GREAT! So far…
After getting TFS up and running, as advertised, on a single server with no domain membership, everything was working great. Did the full tilt, SQL Server Reporting Services (SSRS), SQL Server Analysis Services, and let TFS install WSS 3.0.
Making it externally accessible – Try 1 – Changing netbios names to FQDNs
Of course I couldn’t leave well-enough alone, so I had to take it to the next level. I wanted to see if I could expose TFS so that remote people could access the system. By default TFS uses port 8080, creates a WSS 3.0 web application on port 80 and uses SSRS on port 80. This may be fine for internal networks, though most security conscious organizations would still have 443 and SSL for all of the above even for internal only access. So I decided to use ISA Server 2006 and port forwarding / mapping to solve the SSL issue from outside and leave the inside as installed. Since this was simply a prototype, I wasn’t so concerned with securing the inside.
I created a few ISA firewall rules. You may not be using ISA, but this should be the same on your system with some subtle differences. I mapped 443 to 8080 for the ‘/tfs/*’ path. I mapped 443 to 80 in a separate rule for SSRS paths (‘/reports/*’ and ‘/reportserver/*’) so that logs would be differentiated, and then mapped 443 to 80 for TFS’s SharePoint path (‘/sites/*’). I accepted calls on a public URL and mapped them to the box name. Of course, it blew up on me.
TFS uses WSS’s web services to create its sites. So mapping only ‘/sites/’ did not work, and not to mention that TFS has paths stored that use the box name and ISA was not rewriting the URLs. So SSRS was a BOOM too.
My quick solution didn’t work. I opened up the Team Foundation Administration Console, and started making changes, setting up all the references to WSS to an FQDN. I went into SharePoint Central Administration and added an Alternative Access Mapping and then moved on to the SSRS settings. However, no matter how I tried, the SSRS mappings could not validate the credentials of the service account. FAIL. TFS started warning me that the configuration wasn’t supported because it thought that the SSRS was located on another server and this server wasn’t part of a domain which is the only supported configuration for multi-server installations.
Microsoft should put a sound and warning label that pops up when things like this happens that says, “uh uh… try something new”.
Try 2 – Adding the machine to a domain
After some quick consideration, and thinking of eliminating the error at hand, I decided to add the machine to a domain. So, not wanting more trouble than necessary, I uninstalled TFS, and uninstalled WSS, and even uninstalled SQL so as not to complicate things. I added the machine to a domain and began reinstalling everything. Went through the same configuration, with the exception of moving on to ‘Advanced’ configuration and setting FQDNs up front. Partial FAIL. Not all the accounts were resolving properly. A little tinkering later, nothing major, just checking permissions and DNS entries for the FQDN… SUCCESS! Internally…
Using similar firewall rules as before, except with FQDNs in place, I tried creating a project again. FAIL! TFS was now using FQDNs, but the links’ ports were not going 443 from external, so when it tried to create the associated WSS site, and map to SSRS… BOOM.
Try 3 – Do it right and make it all SSL
After that bout of frustration, and realizing I should have just done it properly the first time, I decided to secure the whole environment. I generated a certificate from a domain controller with cert services installed. I installed the certificate. Went into IIS and bound the certificate to the SharePoint site. Went into SharePoint Central Admin and created a new Alternate Access Mapping (AAM) for the https protocol. Opened SQL Reporting Services Configuration tool and set it to use SSL, and finally changed TFS to call the components using SSL. I tested it locally on the server since I made a few changes that I wanted to verify before trying it from outside the network… SUCCESS! So far…
I changed the firewall rules to make their calls on 443 instead of 80 and VOILA! (don’t hate the french. 😛 hahah)… SUCCESS again! Well almost…
I had to add the account I was using to the Site Collection policy as full-control, and had to add the account to the SSRS database in the db_reader role.
If you’ve made it this far through this post, I applaud your perseverance. If you’ve just skimmed, I hope you found what you were looking for…
The moral of this story… I would have saved myself a bunch of tinkering by just doing it right the first time and making the whole system use SSL, though I did learn more about how TFS does its business by messing up, and now have content for a post. 😉
I hope this saves someone some time and energy.
I’ll post again after playing with TFS and let you know what I think if you’re interested.
PS… as always, questions, comments, concerns are all welcome. :) Be nice! 😛 hehe.
Microsoft’s Install and Configuration Doc as of 4/20/2010
Microsoft’s Direct Download Site: Download details- Team Foundation Installation Guide 2010
Speaking of which, happy 420 for those of you out there, because we all know someone!