Since Brian Keller and Brian Harry requested me to test Configuring Visual Studio 2005 Team Foundation Server with Windows SharePoint Services 3.0, I came up with the following testing strategies to test all kind of options and see if it's still serviceable.
- Team Foundation Server -> Upgrade WSS 3.0 -> Service Pack 1 -> Repair option Add/Remove
- Team Foundation Server SP 1-> Upgrade WSS 3.0 -> Repair
- Team Foundation Server SP 1 / SSL-> Upgrade WSS 3.0 -> Repair
- Team Foundation Server SP 1 / FQDN -> Upgrade WSS 3.0 -> Repair
For the latter I wanted to use my own blog posts, but other people referred to me to use the FQDN post of Buck Hodges. Buck explains in just three points, for answering the 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?" I asked myself the question "Could it be so simple?". The answer to this is NO. By the way I know the original answer was provided by Bill Essary (Software Architect for Team Foundation Server), so I don't blame you Buck 😉
I shall explain in this post why I like to request Microsoft to create a How To on MSDN. Maybe another great project for Brian and his team ;-).
The post starts in the middle of setting up your server, because before you can use a FQDN you have to create one. To setup a FQDN and use this on a Web Site read my first post about FQDN. See http://bloggingabout.net/blogs/mglaser/archive/2007/01/26/hosting-reporting-services-on-a-fully-qualified-domain-name-fqdn.aspx.
The post describes to use TFSAdminUtil for registering a FQDN. Although TFSAdminUtil is a great utility, it misses some parameters for ActivateAT. Microsoft thinks when you setup a FQDN, you will use this hostname for all three Web Sites (SharePoint, SharePoint Admin, Team Foundation Server). Personally I think you separate SharePoint and TFS and probably the Admin site as well (e.g. portal.domainname.com, tfs.domainname.com). What does ActivateAT do and how can you use it. Mainly it changes everything below to be used for a single FQDN. I added some remarks to it. This way I want to show it is advisable to add some additional parameters to the TFSAdminUtil. (Suggested parameters: TFSAT, WSSAT, SSRSAT, WSSAAT.) I divided the tool in which actions it does to update TFS.
- Changes all address rows in the tbl_subcription table of the TFSIntegration database to use the new application server name. (All address rows uses links to the TFS web site)
- Changes all type 3 & 4 url rows in the tbl_service_interface table of the TFSIntegration database to use the new application server name.
A) ReportsService (SharePoint web site or separated Report Server web site)
B) BaseReportUrl (SharePoint web site or separated Report Server web site)
C) DataSourceServer (Why does MS changes this?, It would be better to use the NetBIOSName)
D) WssAdminService (SharePoint Admin web site)
E) BaseServerUrl (SharePoint web site)
F) BaseSiteUrl (SharePoint web site)
G) BaseSiteUnc (UNC path, so use NetBIOSName as well)
- Changes the value rows in the tbl_registration_extended_attributes of the TFSIntegration database to use the new application server name.
These registration attributes are used by the TFSAdminUtil to determine if the user gets a question to change its Application Server.
- Restart IIS
The post continued to mention "After using the TFSAdminUtil you must update the registry for ReportServer and *.config of the Web Services and NT Services."
What are we missing here.
- As seen in my post you have to enable Reporting Services again to be used as a standalone server (http://portal.domainname.com/reports). See http://bloggingabout.net/blogs/mglaser/archive/2007/01/26/hosting-reporting-services-on-a-fully-qualified-domain-name-fqdn.aspx.
- If you upgraded to WSS 3.0 and I bet you did if your read Brian's blog, you must change the Alternate Access Mappings. See http://bloggingabout.net/blogs/mglaser/archive/2007/01/31/hosting-sharepoint-on-a-fully-qualified-domain-name-fqdn.aspx
- For some extra info about the Registry update and the *.config check some other blog posts:
Hosting Team Foundation Server on a fully qualified domain name (FQDN)
Hosting Team Foundation Server on a fully qualified domain name (FQDN) Part II
Automatic Logon in fully qualified domain name (FQDN) environment
I hope I explained why it's so important to have a proper guide about how to setup TFS for a FDQN. Besides this Microsoft is delivering some tools which are great to use for a single FQDN, but since most of my customers want to use a separated FQDN for each Web Site, I'm not happy with it. Luckily most of the configuration are stored in the database, config's, and the registry so it isn't hard to find corresponding keys. I know Microsoft like to refer to TFSReg, but since I'm a data dude and the given connections configuration XML file on MSDN contains some rubbish (http://DTMachineName/ReportServer/ReportService.asmx [I prefer to use the ATMachineName], RosettaService/ReportService.asmx [doesn't exist], http://ATMACHINE:4554/_vti_adm/admin.asmx [wrong port number, talking about serviceable]) I update directly in the database.
Maybe it's a good moment to poll if people are interested in FQDN for TFS guide. Maybe you can post a comment, for requesting one.