One of the major selling points of TFS is the fact that so much of the system is accessible from the web. The SharePoint portal gives access to project documents, charts, and artifacts while the Web Portal allows your team to directly access work items, queries, and the code base. The problem comes when the team or client asks for the URL to get at these resources. The SharePoint site has a very long URL and the Web Portal is even worse putting the project GUID right in a querystring. In this post, I’ll show you how to use the URL Rewrite Module 2.0 to build friendly URLs for these sites.
Project Name: PoC of TFS
SharePoint Dashboard: https://<Server 2 URL>/sites/<Collection Name>/PoC%20of%20TFS%20Dashboards/Dashboards/Burndown.aspx
Web Access: https:///tfs/web/?pguid=63b43f78-6cae-4569-bd19-5059b25bdad8
Not very friendly at all and completely impossible to communicate over the phone. You’ll note that I am using SSL and separate servers for the TFS and SharePoint instances, but this won’t be any different if you are running everything on one box.
Here we go…
1. Gather the URLs that you would like to redirect. As above, it will save you time if you collect them all at once. Unfortunately, we will be creating static rules. Because the URLs are stored in the database, it would be possible to create a job that outputs the appropriate XML to do the redirects automatically, but I’ll put that in a future posting.
2. Download and Install the URL Rewrite Module 2.0 This is a simple download and click “go” kind of install. In this case, I have chosen to put this on the main TFS server to prove that it can co-exist with all of the other modules and web services that TFS spins up. You might choose to put this on a separate server if you think the load is going to be extreme, but I don’t see that as necessary.
4. Create the Rewrite Maps — I find it helpful to create a single mapping for all of the rewrites that I am going to use on the server.
4.1 Click Add Rewrite Map
4.2 Name the Map
4.3 Click OK
5. Create the Rewrite Entries — This generates an XML file that will act as the translator between the source and destination URLs. There are two different kinds of mappings that you can use, but they can be mixed freely. Path Replacements will keep the root URL (server, port, and root path) and simply replace anything after the match. URL replacements will do a complete redirection and can be used to bounce to a completely different server. We will be using both, but luckily the tool is smart enough to figure this out without a lot of configuration.
5.1 Click Add Mapping Entry on the upper right pane
5.2 Create the Dashboard Mapping (URL Replacement)
5.2.1 Input the Friendly Value and the True URL
5.3 Create the WebAccess Mapping (Path Replacement)
5.3.1 Input the Friendly Value and the True URL
5.4 Click Back to Rules in the upper right pane
6.1 Set the Rule action to Redirect — This will essentially forward to the real address. it would be nice to do a rewrite as it would masquerade the address, but this has an effect on the authentication model causing the pages not to work. It is more reliable to do a redirect and simply use the forwarding rule as a communication vehicle. Further, if the end user is to bookmark the “real” address, there is no true issue as they’ll still get to the page and there will be lower overhead on the redirect service – Win/ Win!
6.2 Choose the Rewrite Map that you created earlier in the drop down.
6.3 Click OK
There you go; you’re done. If you create redirect rules for each fo the projects you are maintaining as they are created, you will have friendly URLs that are client consumable and easily documented!
Now my URLs are much simpler and are easily understood by the client: