From Wikipedia …
A fully qualified domain name (or FQDN) is an unambiguous domain name that specifies the exact location in the Domain Name System’s tree hierarchy through to a top-level domain and finally to the root domain. Technically, a FQDN has a trailing dot (for example: somehost.example.com.), but most DNS resolvers will treat any domain name that already has a dot as being an FQDN and add the final dot needed for the root of the DNS tree.
A lot of companies will use FQDN what means that Team Foundation Server won’t work with the default installation procedure. At first sight, you might think it works, but for Windows SharePoint Services and Reporting Services it won’t! There’s a pretty good blogpost from Buck Hodges available that guides you how to modify the default TFS configuration. Here’s what I did to get TFS working with FQDN :
- Run tfsadminutil activateat MyFQDN. This command (tfsadminutil can be found in the Tools folder of the TFS installation folder) will activate the FQDN computer as the TFS application-tier server. One of the executed tasks is the modification of the global TFS web.config (config file can be found in the Web Services folder of the TFS installation folder). You may verify the TFSNameUrl setting in the configuration file. I also manually added the appsetting TfsUrlPublic with as value the http://*FQDN*:8080 to force FQDN references in e-mail notifications. Another task the command does is changing the TFS service interface. You may verify this in the tbl_service_interface table of the TfsIntegration database. All urls should now match the FQDN. Before all urls contained the netbiosname of the computer.
- Update registry settings BaseReportsUrl and ReportsService with my FQDN at HKLM\SOFTWARE\Microsoft\VisualStudio\9.0\TeamFoundation\ReportServer\80\Sites.
- For WSS 3.0 to work with TFS 2008, I still had to add an alternate access mapping (see blogpost Buck Hodges how to cope with that).