How to setup a dns friendly Team Foundation build service environment in TFS 2012

When we setup a Team Foundation build environments, we focus on getting the environment as dns friendly as posible. We don’t want the build masters to spend time resolving obscure machine names, and certainly not rembemer them! When the build master get notified on build service issues, he should be eable to directly RDP to the correct machine based on the logical domain and not the physical (i.e. machine names). So i figured i just share our 5 cent’s on how we setup an dns friendly TFS build environments. You can see this as an extension of Ed Blankeships blog on setting up dns friendly TFS environments.
The convention is quite simple and it makes it’s very easy to RDP to the correct build server when issues are reported by the development teams.
Naming convention for build controllers:

buildcontroller.<collectionname>.contoso.local
i.e. buildcontroller.defaultcollection.contoso.local

Naming convention for build agents:

build<number>.<collectionname>.contoso.local – Agent <number>

build1.defaultcollection.contoso.local – Agent 1
build1.defaultcollection.contoso.local – Agent 2
build1.defaultcollection.contoso.local – Agent 3

build2.defaultcollection.contoso.local – Agent 1
build2.defaultcollection.contoso.local – Agent 2

We recycle the agent number on each build server since it is a local resource.
In some scenarios build agents and buildcontroller are on the same machine, if so we don’t skip one of the dns aliases; we don’t want to break the convention. i.e. the machine QOPRSA12312.contoso.local has both buildcontroller and build agents installed, so we make two dns aliases:

buildcontroller.defaultcollection.contoso.local  –> QOPRSA12312.contoso.local
build1.defaultcollection.contoso.local             –> QOPRSA12312.contoso.local
The reason for having build service name first and not collection name, is that this corresponds to the logical grouping in the organization; Teams work on work on Team Project collections, not on build services, so the ALM view should reflect this. i.e on the domain controller resources are grouped by collection names not buildcontroller og build machines (see image below).
On the domain controller:

This how it looks visual studio:
The build log:

So if there is a problem the build master can now just RDP directly to build1.defaultcollection.contoso.local:

We are open to opinions on how this is setup, but in our environment and for our customers this works very well .
Happy ALM’ing