Setting up various topologies to test with Visual Studio Lab Management – Part 4

 

In continuation with our topology series, this time we will pick a topology with multiple ATs, DTs and with Lab Environments joined to different domain for discussion. We will touch upon Lab Management specific requirements and configuration for this topology. Take a look at Part1, Part2 and Part3 for our earlier discussions on topologies.

Here is a quick recap on acronyms

• Corp network – Would refer to the corp. network where TFS is hosted. A Corp network would have one or more ATs, DTs, Load balancers, Proxy, VMM server. Clients are typically connected to this network while at work.
• Test network – Would refer to the network where the testing of the apps would happen. Test controller, Build controller, VMM server, VMM Library VMM hosts are present in this network. Please note that VMM server can either be in Corp network on in Test network depending on your choice.
• Corp Domain – the domain controller in corp. network
• Private Lab Domain – the domain controller in Private Test network.
• AT – Application Tier
• DT – Data Tier
• VMM – System Centre Virtual Machine Manager
• TC – Test controller
• BC – Build Controller
• BSH – Build Service Host
• NLB – Network Load balancing
• VM – Virtual Machine
• LE – Lab environment
• LS – Lab system within Lab Environment

Topology #4 – Topology with multiple ATs and DTs, load balancers and Environments joined to a different domain

This topology has multiple application tiers, named data tiers and a load balancer in its Corp network. The Test network has VMM server and its library and host group, Test and build controllers.

The interesting aspect in this topology is we have separate Corp and Lab AD that have no trust between them, however the Corp and Lab DNS have DNS forwarding configured to see the A records in other zones respectively. The test apps that are deployed for testing are joined to Lab AD.

We will also assume that in this topology the ATs, VMM server, Controller and the host are assigned static IP. It is not a requirement to have static IP for these components. All our previous topology discussions in Part1, Part2 and Part3 did not have this requirement and were assumed to use IP allotted by DHCP; we are considering static IP for this discussion just to illustrate that Visual Studio 2010 Lab Management works fine even with these configurations.

1) TFS configurations

Part2 covers multiple application tier installation and configuration with multiple named data tiers. So we will not be covering them again here.

As mentioned in Part1, and Part3, with the use of a load balancer, you will have to take care of appropriate notification URL and Lab URL. Other than that there is nothing Lab Management specific configurations that is required. I have mentioned F5 NLB here to illustrate that Lab Management can work with both hardware and software NLB mechanisms.

The App tier configuration for this topology looks as below once configured

The Lab URL settings is as below

The bindings in IIS for TFS website looks as below. You will notice that there is explicit IP, Port and SSL binding for HTTPS and default binding for HTTP.

2) Static IP

Application tiers, Data tiers, VMM server, VMM library, VMM host, Test and Build controllers can all be configured with static IP. Ensure appropriate DNS and Gateway is configured in their adapters.

For Environments created out of Golden VM templates, it is advisable to use DHCP to allot IP. Since the sysprep templates would not retain any DNS and Gateway adapter configuration settings during specialization, without a DHCP the Lab systems in the Environment will not be properly connected to network post Environment creation.

For cloning of environments with Network isolation it is mandatory to have DHCP in your Corp/Test network to successfully clone environments without IP conflicts.

3) Lab Environments joined to different domain

I would like to emphasize again that, in Visual studio 2010 Lab Management release we require TFS (AT/DT), VMM server, VMM host, VMM library, Test Controller and Build controller all be in same trusted domain. Visual Sutdio 2010 Lab Management do not support any of them being in a partially trusted or in no trust domains.

However, you can have your Lab environments created and joined to a different domain.

LE creation

You can create Lab environment out of Golden VM templates from library and have the OS profile edited to join to a domain which is other than what your client or TFS is part of. In the LE creation wizard, you will have to fill in the domain credentials and password in OS profile tab.

Clicking on “Test” after providing the credentials will show a warning as below. This warning appears if your client is in a domain that is not trusted with the domain that you filled in the OS profile. However, this is just a warning, so you should be able to proceed further by clicking “Finish” and initiate LE creation.

DNS forwarding & WINS

For a topology like what we have taken up for discussion, It is important for Lab environment to have connectivity to reach DNS in Test network to resolve its domain controller and to join the Lab AD.

It is also important for Lab environment to have connectivity with TFS and Controllers that are in Corp network for the Testing and Workflow capability to work fine.

Given these requirements, the topology for discussion is such that, there is single DHCP that allots IP to machines in Corp network (example your client) and to Lab environments created in Test network. The machines will have Corp DNS as the primary DNS as given by the DHCP. Hence both the Corp domain joined machines and Lab Domain joined machines will have Corp DNS as their primary DNS.

The TechNet article explains in detail the steps required for configuring DNS conditional forwarding.

To summarize:

• The Lab environments should have DHCP IP allotment and have primary DNS as Corp DNS.
• The Corp DNS should be configured to forward the requests meant for Lab DNS zones to Lab DNS.

This will ensure that build agent within Lab environment (in Lab domain) is able to resolve and reach TFS and Controller (in Corp domain) and vice versa.

Unlike Build controller, instead of using FQDN of agent machine, Test controller attempts to connect back to test agent using IPV4 address or using bare host name based on certain criteria. Using bare hostname is not a problem if both the agent and the Controller are in same domain. Since they share the same primary DNS suffix, the name resolution will not be a problem even if Controller attempts to resolve using agent’s bare host name. TechNet article explains in detail the name resolution logic when a bare host name (single-label unqualified domain name) is given.

However, in topology like ours where the Controller is in Corp domain (say Corp.com) and the Agent is in Lab domain (say Lab.com), name resolution will fail because the Controller attempts to resolve the name by adding its own primary DNS suffix (which will be Corp.com). Hence for topologies like this, you will require a WINS server so that Test Controller can resolve the Test Agent’s bare name using NetBIOS.

To summarize;

• If you have Lab environments joined to different domain other than Test controller and if any one of the following criteria is true then you will need a WINS server for Test controller to resolve agent’s bare host name using NetBIOS. 
  • Lab environments are IPV6 capable
  • Lab environments have lab systems that are multi-homed
• If your above condition is true but you do not want to install WINS, then you will have to explictly configure in each of the Lab systems, and provide IP address to which the test agent will be bound to. This configuration is done in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\QTAgentService.exe.config

 

.

•  For all the other conditions, you don’t require a WINS. Test controller will be able to resolve the agent with the DNS or by connecting directly using IPV4.

4) Topology variations and its impact on Visual Studio 2010 Lab Management

Visual Studio 2010 Lab management will behave as given below, for the given topology variations

Isolated Test network

You cannot have Test network completely isolated from Corp network. If you have such a topology then the test agent or the build agent will not be able to talk to TFS or the Test/Build Controller which are in Corp domain. Hence you will not be able to leverage the testing and workflow capabilities in such a topology. You can however be able to operate on the Lab environment and do the basic Lab environment operations on it.

Without DNS forwarding

Even if you choose to have TFS and Controller as multi-homed and connected to Test Network in addition to Corp Network, the TFS or Controller will always attempt to resolve the agent name in their primary DNS which will be Corp DNS. Hence it is important to have the DNS forwarding configured in the primary DNS to be able to resolve the Lab DNS zones.

Different Primary DNS for Test and Corp network

In our discussion above we said that Corp DNS will be the primary DNS for both Corp domain joined machines and Lab domain joined machines. However, you may choose to have different DNS as your primary DNS in Corp and in Test networks respectively. In such cases, you will need to enable DNS forwarding in both the DNS such that TFS and Controller can consult Corp DNS to resolve Agent (in Lab DNS zone) and vice versa where Agent can consult Lab DNs to resolve TFS and Controller (in Corp DNS zone).