This week the following question came up.  I've seen this come up before, and there are probably forum threads on it, but I figured I'd post it here.  Bill Essary provided the answer to the question.  As always, keep notes on what you do so that you can undo it if necessary.

Question

Is there a way to configure TFS to use fully-qualified domain names (FQDN, e.g., tfsserver.mycompany.com) for TFS, WSS, and Reporting Services?

Answer

1) Run "tfsadminutil activateat <FullyQualifiedDomainName>"

2) Update the following registry key with the FQDN: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\ReportServer

3) To force FQDN references in e-mail notifications, set TFSUrlPublic in the TFS root web.config file to http://<FQDN>:8080.

There are a handful of other places where the TFS URL is stored, but they typically wouldn't matter if the goal is to ensure that all public access to the server is done via FQDN.  The ones that are missed govern communication local to the TFS AT (ex: TFS scheduler prodding TFS warehouse).  If you want to get them all, use the SSL-only configuration topic for TFS as a guide.

4) Add the domain to the Intranet Zone or Trusted Sites list in IE for all clients (see KB 303650)

If you are using TFS 2008 with SharePoint 3.0 (or Microsoft Office SharePoint Services 2007), you will need to do the following as well.

After following the steps above with TFS2008 + WSS 3.0 you will observe that when you try to access the team portal using http://FQDN/sites/TeamProjectName you will be automatically redirected to http://NETBIOSNAME/sites/TeamProjectName. 

This behavior is by design and is caused by alternate access mapping. In order to avoid this you will have to create a custom alternate access mapping which has the FQDN as the internal URL and as the public URL.

  1. Open WSS3.0 Central Administration
  2. Click on Operations tab
  3. Click on Alternate access mapping
  4. Click the Add Internal URLs button
  5. In the dropdown select the default website (port 80)
  6. Enter the FQDN in the textbox
  7. Set the Zone to Custom

Additional step required when .NET 3.5 SP1 is installed 

If you have Service Pack 1 for .NET 3.5 installed on your 2008 server (and if you do, make sure you also have SP1 for TFS 2008 installed), you will need to make an additional change.  KB 926642 describes what you will need to do.  The registry change is probably the simplest approach, but you will need to decide which approach is best for you based on the security tradeoffs.

The need for this setting is due to the fact that .NET 3.5 SP1 includes changes to support Windows' features to defeat reflection attacks.  Unfortunately, that causes problems with the way FQDN support works in TFS.  You can find additional background on the Windows' security settings at Getting Caught by Loopback.  You can also read about the impact on SQL Reporting Services at Reporting Services HTTP 401 (Unauthorized) - Host Headers require your attention.

[UPDATE February 27, 2008] Ladislau Szomoru provided additional steps required when making this change with TFS 2008 and SharePoint 3.0.

[UPDATE October 17, 2008] I've added information about handling the new security checks enabled by .NET 3.5 SP1 that will prevent FQDN from working without taking additional steps.

tags: ,