I want the server to refer to itself ONLY by the FQDN.
http://img116.imageshack.us/img116/2330/properties9sk.jpg
if you have a look in the image - the server name is Fully Qualified, although the link that it will send the user to is not.
how do i make them both be the same? FQ?
thank you.
The link that the server sends to the client is generally constructed based upon the prototocol and server name used to connect to the server. If you clear the TFS cache on the client and then reconnect using a FQDN, you should see that the client uses that FQDN. There are a few places where TFS uses "absolute" URLs, and if you want a complete FQDN solution, you will need to update those places as well. Here is how you do that:
Update TFS registration data:
1) Open a command shell and cd to "%programfiles%\Microsoft Visual Studio 2005 Team Foundation Server\Tools" on the TFS AT machine.
2) Run "tfsadminutil activateat <FQDN>"
Update TFS URLs:
1) To force FQDN for reports displayed on the SharePoint site, update the Key value of the following registry location with the FQDN: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\ReportServer.
2) To force FQDN references in e-mail notifications, set the TFSUrlPublic value in the global config located at %programfiles%\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\web.config. Change to http://<FQDN>:8080.
TFSNameUrl would normally be updated when you run the acitvateat command.
My mistake... activateat does not touch the web.config file.
The TfsNameUrl normally would not need to be updated to use the FQDN and so the tool leaves it alone. The setting is used for server-to-server calls between TFS components. For instance, when the Work Item Tracking application starts, it looks to the TfsNameUrl as the the place to find services/v1.0/registrationservice.asmx. You could update the TfsNameUrl to use the FQDN manually, but it should not be necessary.
Thanks! I found it out myself in the meantime. I am becoming quite an TFS admin expert anyways ;)
There is one situation when this needs to be updated: I have configured my TFS server such that the WSS (and reporting) site and the TFS web services run on the same port, but use different FQDNs. So ServerBindings for IIS has ":80:www.tfs.mycompany.com" for the WSS website and ":80:tfs.mycompany.com" for the web services site.
In that case the name in the web.config needs to be updated, since web service calls to http://TFS:8080 will no longer be served. Actually, one needs also to update the web.config for the scheduler (and maybe one more? I forgot).
I am now attempting to use SSL, if you wouldn't mind looking at my newest posting on that here in the forum, I would much appreciate it!
There is one more config file that needs the update in that case: CoverAn/CoverAn.exe.config.
Moving everything to port 80/443 using host headers... nice! I'm sure the community would love to see a summary of your experience when it is all said and done.
Well, wait until I start moving everything into one IIS Web Site ;)
By the way, why wasn't that done in the first place?
I am just reinstalling everything again, I will write down my precise steps this time. If I get everything working, I will post it. Doing it on port 80 succeed, but doing everything over SSL on port 443, gee, complicated...
Ah, sorry, that was not what I meant. Why didn't you just put everything under one IIS web site?
Could you not have excluded some directory "tfswebservices" from the sharepoint namespace on the default web site, created a virtual path to the "C:\Program Files\Mic...\Web Service" directory and not need a third web site at all?
I almost started doing this myself, but there seems to be one problem: The various services all decend directly from the team foundation web site, so normally it is http://TFS:8080/service/v1.0/Registration.asmx etc. If you had picked something like http://TFS:8080/tfswebservices/services/v1.0/Registration.asmx instead, the common web.config could have been placed into the tfswebservices directory. And I don't see why in that case one could not create a new virtual directory on the main site that has the name tfswebservices and points to the web service directory as well. It seems to me that would have been a soo much nicer solution: Everything would have worked over on port, one DNS name. No need for host header configuration or anything like that at all.
Yes, that is true, the Sharepoint admin stuff always needs its own port.
Here is my wishlist in this area:
- Support having the TFS web services and the Sharepoint sites on one IIS site. That would make client access sooo much easier, SSL configuration would be super simple as well. And clients could connect using only one port and one DNS name, which would be great. If this configuration could be supported in SP1 :)
- Don't require access to the Sharepoint admin site from the client for team project creation. As far as I can tell that is the only point when the client connects to that web service (by the way, is that correct?!?). Ideally the client would only communicate with the TFS web service, and that one would call into the sharepoint admin stuff locally on the app tier. Maybe V2?
Best,
David
