January 3, 2011 4:47 PM
by Ed Blankenship
Over the past few years of dealing with plenty of TFS environments, one thing that I am glad to have done is setup friendly DNS names for TFS to use for it’s individual parts. This has helped extremely to make for a smooth transition for administrators & end users when needing to move TFS to a new hardware environment, upgrading TFS to a new version, or in several disaster recovery scenarios. Not to mention having to tell new users to connect to some odd server with a weird name like ADGKSDFU308234NT. You can obfuscate all of the connection points that TFS uses. The concept is easy and if you haven’t done it already, it’s never too late.
I mentioned a few examples above but let me expand on it a little further by presenting two scenarios that I have run across. There are plenty of other scenarios that have been handy in the past as well. You’ll be surprised the options you have for different types of changes to the infrastructure and topology that you’ll run across in the future by using friendly DNS names.
During a future upgrade, it is decided that new hardware is to be used for scaling out to increase the availability and performance of the TFS environment. By using friendly DNS names, end users and custom tools can continue to point to the same address (tfs.contoso.local) without making any changes. This allows for having the old environment up at the same time as having the new upgraded environment up. This helps out with rollback plans in case the upgrade was not successful.
A company has noticed that heavy usage of the OLAP warehouse cube in SQL Analysis Services has started to use a lot of the RAM on the data tier server. They would like to separate SQL Analysis Services from the database services in SQL Server to a separate server. By changing the friendly DNS name (warehouse.tfs.contoso.local) to the new Analysis Services instance, end users who have created custom Excel pivot table reports in workbooks won’t have to update each workbook.
Any others you can think of?
First, you will want to create either A or CNAME records in your DNS infrastructure. If you are using Active Directory then your DNS infrastructure will more than likely be managed by your domain controller(s).
This guide assumes that you are using the following friendly DNS names throughout the configuration. In this example, the internal network uses the DNS suffix of contoso.local. You could also have contoso.com addresses point to internal servers if they are setup appropriately in DNS. Check with your DNS administrator to discuss which format should be used. Be sure to use fully-qualified DNS names especially for those clients that use VPN or have remote offices. You will want to be sure to follow the guide in order since some steps are dependent on previous steps to have been performed.
Application Tier or Network Load Balance IP for TFS AT Farm
Used For: TFS Web Services, Team Web Access, SQL Reporting Services, and SharePoint (if on same box)
Data Tier or SQL Server Cluster IP
Used For: Location of Configuration, TPC, and Relational Warehouse Databases
SQL Analysis Services Instance
One friendly DNS entry for each remote location. (Optional)
Separate friendly DNS entry for the SharePoint server if separate from the application tier. (Optional)
In my particular example below, I have a single server that has both the application tier components and the data tier components. SQL Analysis Services is also installed on the same server. However, I am using a separate SharePoint server and a different server for TFS Lab Management.
Often when you are logging into a server and using a friendly DNS name that resolves back to itself (localhost) you will find that you end up having authentication issues because of a security feature in Windows Server. You can disable this security feature by following the directions in this KB support article: http://support.microsoft.com/kb/896861. You will want to do this for each of the servers that may resolve back to itself using the friendly DNS name. For example: application tier servers, data tier, Analysis Services server, SharePoint servers, etc.
To set the DisableLoopbackCheck registry key, follow these steps:
When initially configuring Team Foundation Server, use the fully-qualified friendly DNS name for the data tier server: data.tfs.contoso.local. If this is done correctly, then the Application Tier information page on the TFS Administration Console will show that friendly DNS name in the connection string.
Also use this location for each team project collection that is created as well. If it done correctly then you will see it shown for the connection string to the team project collection database.
If TFS has already been setup and configured not using the friendly DNS name, you can alternatively use the TFSConfig.exe RemapDBs and RegisterDB command on each application tier server to update its data tier server connection string to use the friendly DNS name.
tfsconfig.exe remapdbs /DatabaseName:data.tfs.contoso.local;Tfs_Configuration /SQLInstances:data.tfs.contoso.local
More information about the RemapDBs command can be found on MSDN: http://msdn.microsoft.com/en-us/library/ee349262.aspx
tfsconfig.exe registerDB /SQLInstance:data.tfs.contoso.local /DatabaseName:Tfs_Configuration
More information about the RegisterDB command can be found on MSDN: http://msdn.microsoft.com/en-us/library/ms252443.aspx
You may want to also update the public URL for SharePoint to use for the Central Administration site as well. Perform the same steps except choose the SharePoint Central Administration in the Alternate Access Mapping Collection combo box.
The Team Foundation Server Administration Console should now display the appropriate information as shown below.
Be sure to also configure all of the build servers and proxy servers to point to the friendly DNS name when connecting to the application tier server(s). This will allow for the same type of flexibility whenever you need to make any TFS environment topology changes.
Let me know if you have any additional questions!
Is there a way to rename the Tfs DBs ("tfs_Warehouse" and "tfs_Configuration")? Our SQL team has a naming convention for DBs, and the way TFS assigns name for TFS Dbs doesn't fit the required naming convention, even if I used the label to add a customized label to the DB names. Can I rename the TFS SQL Dbs, then edit the configuration information to change to the new names?
you recommand installing TFS tiers directly using their FQDN names, I try to do that as well. This requires DNS aliases to be active : for example I could not set up the app tier in FQDN by editing the hosts file.The problem with that is with the flexibility aliases are suppose to provide in an upgrade scenario, if the alias has to point to the new machine (the one being installed) then there is a service discontinuity regarding to the current (old) server.How do you actually proceed to maximize TFS up time during an upgrade with a single alias ?
a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u
Hi! I am Ed Blankenship and a Product Manager at Microsoft for Visual Studio Online, Team Foundation Server, and the Application Lifecycle Management family of tools. I am an author of a few books, former Microsoft MVP of the Year, and a former ALM consultant.
Powered by Azure Websites
Site design by Jeremy Kratz