By default the TFS server uses http://localhost:8080/tfs as it’s Server URL, this is the URL used for internal communication, whereas the Notification Url is the one TFS tells client to communicate to it via. Both these Urls can be changed via the Team Foundation Server Console, but I find you do not usually need to change the Server Url, only the notification one.
I hit a problem recently on a site where if you tried to edit the Team Project Collection Group Membership (via the web or TFS admin console) you got a dialog popping up saying ‘HTTP 400 error’. Now this you have to say looks like a URL/binding issue, the tools cannot find an end point.
Turns out the issue was that there had been a IP addressing schema changes on the network. The different services on the network had been assigned their own IP addresses (as well as the host having its own IP address) e.g. On our TFS server we might have
- 10.0.0.1 – physicalservername.domain.com
- 10.0.1.1 – tfs2012.domain.com
- 10.0.1.2 – sharepoint.domain.com
This is all well end good, but a mistake had been made in the bindings in IIS during the reconfiguration.
The HTTPS bind was correct the hostname matched the IP address, this has to be the case else SSL does not work. However, the HTTP port 8080 should have been bound to all IP Addresses (i.e. no hostname and the * IP address as above). On the site, HTTP was bound to a specific IP address. This was fine if a client connected to http://tfs2012.domain.com:8080/tfs (which resolved to the correct address), but failed for http://loclahost:8080/tfs as the binding did not match.
Once the edit was made to remove the hostname all was OK (the other option would have been to alter the server Url to match)
So problem fixed, the strangest thing is that this issue only appeared to effect setting TPC group membership, everything else was fine.