Getting TFS 2012 Agents to communicate cross domain

author Richard Fennell calendar Jul 20, 2012 · 6 min read · Uncategorised  ·
Share on: linkedin copy

I don’t know about your systems but historically we have had VMs running in test domains that are connected to our corporate LAN. Thus allowing our staff and external testers to access them from their development PCs or through our firewall after providing suitable test domain credentials. These test setups are great candidates for the new TFS Lab Management 2012 feature Standard environments. It does not matter if they are hosted as physical devices, or on Hyper-V or VMware.

However, the use of separate domains raises issues of cross domain authentication, irrespective of the virtualisation technology. It is always a potentially confusing area. If we want the ability to use the deployment and testing features of Lab Management, what we need to achieve is Test Agents on each VM, that talks to a Test Controller which is registered to a TFS Team Project Collection. Not too easy when spread across multiple domains.

With TSF2012 the whole process of getting agents to talk to their controller was greatly eased. Lab Management does it for you much of the time if you provide it with a corptfslab domain account who is a member of the Project collection test service accounts group in TFS.

The summary of the scenarios is as follows

Scenario

How to achieve it

If your test VMs are in either a SCVMM managed or standard environment but are joined to your corp domain

Lab Management wires it all up automatically using your corptfslab account

If your test VMs are in either a SCVMM managed or standard environment that is not domain joined i.e: just in a workgroup

Lab Management wires it all up automatically using your corptfslab account

If your test VMs are in a SCVMM managed network isolated environment

Lab Management wires it all up automatically using your corptfslab account

If your test VMs are in either a SCVMM managed (not network isolated) or standard environment and are in their own test domain

You have to do some work

If like me you end up with the fourth scenario, the key is to provide a test controller within the test domain. This must be configured to talk back to TFS on the corp domain. This can all done with local machine accounts on the test controller and TFS server with matching names and passwords, what I think of as shadow accounts.

So for example, we have the following scenario of a corp domain with a DC and various TFS servers and controllers and a test domain containing three servers.

image

So the process to get the test agents on the test domain talking to TFS on the corp domain is as follows:

  1. On the TFS server (called tfsserver.corp.com in above graphic)
    1. Open the Control Panel > Computer Manager and create a new local user called tfslabshadow. Set the password and that the user does not need to change it on first login and that it does not expire
    2. In the TFS administration console add the new user tfsservertfslabshadow to the Project collection test service accounts group
  2. On a machine (called server.test.local in above graphic) within the test domain (this cab be any VM in the domain running Windows other than the DC)

    1. Open the Control Panel > Computer Manager and create a new local user called tfslabshadow with the same password as on the same account on the tfsserver

    2. Add this user to the local administrators group for that server.

    3. Login as this user

    4. Install the Visual Studio 2012 Test controller

    5. When the installation is complete the configuration tool will launch. Set the service to run as the tfslabshadow and register it to connect to the TFS server with this account too.
      Note - When you first load the configuration tool you need to browse for the TFS server and enter its URL. If you have your shadow accounts working correctly you should not need to enter any other credentials at this point.
      Note - You can enter the local user name in either the .tfslabshadow or servertfslabshadow format

      image

    6. If you have all the settings correct then you should be able to apply the changes without any errors and the new test controller should be registered. If you get any errors they usually are fairly clear at this point when you look in the log, you probably forgot to place a user in some group somewhere.

  3. From a PC running Test Manager 2012 (MTM) on the corp domain
    1. Go into the Lab Center
    2. Create a new environment (can be SCVMM or Standard) containing the machines in the test domain (or open an existing environment if you have one that was not correctly configured)
    3. On the Advanced tab you should be able to select the new test controller server that is hosted within the test domain
    4. You can make any other setting changes you require (remember on the machines tab to enter the test domain login credentials, they will have defaulted to your current ones). When you are done you can select Verify. I had problem here due to DNS entries. From the PC running MTM I could ping server, but MTM was trying to communicate using the name server.test.local. To get around this I added an entry in my local host files. I have also a seen VMs that are not registered in DNS at all, again a local hosts file fixes the problem. This is only required for the initial verification and deployment/configuration once this is done the host entries can be removed if you want.
    5. Once verification has passed save the changes and after a short wait the environment should finish configuring itself showing no errors

So I hope I have provided a step by step to help you get around issues with cross domain testing in Lab Management. However, it is still important to remember the exceptions

  1. As we are using local machine accounts you cannot have the TFS server or the Test controller running on a domain controller (as a DC cannot have local machine accounts). If your environment is a single box that is a DC then you either have to setup a cross domain two way trust between test and corp or rebuild the environment as a workgroup or network isolated environment.
  2. The shadow account cannot have the same name as the corptfslab account i.e: tfslab. If you try to use the same name for the local machine and domain accounts the matching of the two local machine accounts will fails as on the TFS server end it will not be able to decide whether to use corptfslab or tfsserverrfslab

For more details on this general area see MSDN