Server name in Changeset.aspx
I changed the name of my TFS server in all sorts of places, but there is one left which I can't figure out.
When I get an alert email that something new was checked in, I get an email with a link to the changeset. It ends with /VersionControl/Changeset.aspx?artifactMoniker=16&webView=true. In there is a reference to a XSL stylesheet, but that reference is using the old, original server name. How can I update that one as well?
Thanks,
David
Hi David,
Are you still experiencing this problem? If so, please let me know so I can have someone assigned to provide help.
Thanks,
-Matt
Hi Matt,
yes, this problem is still there.
Thanks,
David
I haven't used this tool for scenario like this before, but maybe it will help you, in TfsAdminUtil.exe you have an option which is "activateat [/i] [<server name>]" which is used to activate the server as application tier serve, if no name is given it uses the actual server in which is run from NETBIOS name
Maybe this will helps you, updating all the references to the new server name.
I have done the activateat thing long ago, but that didn't help.
Best,
David
David,
The links contain a "host name" -- if this is the comman name (CN) and not the physical system name, the links will continue to work.
We don't have a solution for patching Urls that become out of date; best practices for migrating servers should be followed when moving server functionality to a different host.
-jeff
Jeff,
I am afraid I didn't explain myself clearly.
I changed the server name of our TFS server with the activateat from tfs01 to tfs01.mycompany.com. I also changed the TFSNameUrl and the TFSUrlPublic in the web.config in the Web Service directory. But when I then navigate to
http://tfs01.mycompany.com/VersionControl/Changeset.aspx?artifactMoniker=30&webView=true
it can't be displayed in a web browser. And the reason is that the XML that comes back from this URL has this element in it:
<?xml-stylesheet type="text/xsl" href="http://TFS01/VersionControl/V1.0/Transforms/changeset.xsl"?>
Which of course is wrong, because it should reference the stylesheet with the full tfs01.mycompany.com DNS name.
So, the problem is not with old emails, the problem is that TFS does not seem to pick up the new server name for the reference to the stylesheet.
Best,
David
David,
Thanks for the clarification. In web.config (installDir\Web Services\Web.config), update the value of the setting TFSUrlPublic to http://tfs01.mycompany.com:8080 (or, whatever port applies to your site). You should find TFSUrlPublic in a commented our block in the appSettings block. If not, here's a sample
<!-- TFS Url for access from internet, used for specifying links in alerts
<add key="TFSUrlPublic" value="https://www.microsoft.com:8081"/>
-->
As I wrote, TFSUrlPublic is already set to the full DNS name. But the changeset.aspx does not seem to pick that setting up.
Best,
David
David,
Can you verify that TFSUrlPublic is not commented out?
-jeff
TFSUrlPublic is not commented out. Just checked again. Also, the emails that are sent from TFS do pick up the DNS Name from TFSUrlPublic, only the reference to the stylesheet in the XML from the changeset thing doesn't.
Best,
David
David,
Thanks for your help and patience while investigating this issue. I checked the sources and it looks like the reference to the stylesheets are not being formed correctly. I will file a bug.
At this point, I do not have a workaround for you.
-jeff
Excellent and thanks!
Any chance to see this fixed in SP1? This looks like a problem for extranet scenarios, which are one of the things that should work with SP1, right?
Best,
David
Yes, the extranet scenarios will be supported in SP1.
Regarding whether this will be in SP1, I'll contact the servicing folks. It's not likely, however, that this will be included.
One workaround might be to update the hosts file of the clients (not ideal, I know), mapping servername to the IP. Yes, this is not ideal and doesn't handle IP address changes but it may provide a temporary solution.
Hm, the hosts file is not an option. One needs admin rights to do that and we have a number of clients onto which we don't have access.
I'd consider this a key part of extranet scenarios and would strongly urge you to include the fix in SP1. Without this a whole (and important) part of the UI would not work for extranet scenarios, essentially making TFS still unsuitable for that scenario.
Best,
David
