Home azure devops ci/cd test automation troubleshooting

Troubleshooting Azure DevOps: Resolving Test Agent Configuration Failures Efficiently

Updated: • 0 • min read
Table of Contents

This article provides a comprehensive guide to diagnosing and resolving the common error encountered when configuring a Test Agent to communicate with a Test Controller in Azure DevOps, specifically the “No such host is known” error. This issue often arises in complex network environments involving different domains or workgroups, hindering automated test execution.

Symptoms of Test Agent Configuration Failure

Consider a scenario where a Test Controller is operating on a machine joined to a corporate domain, let’s say with a DNS suffix of contoso.com. In parallel, a Test Agent is deployed on a separate machine belonging to a workgroup or a different domain, perhaps with a DNS suffix like fabrikaam.com. Even if basic network connectivity allows machines to ping each other using their fully qualified domain names (FQDNs) and necessary firewall ports are open for the controller and agent services, the configuration process may still fail.

During the Test Agent configuration, when attempting to establish a connection to the specified Test Controller URI (often using the Controller’s FQDN), the tool reports an error. Inspection of the Test Agent configuration logs reveals a System.Net.Sockets.SocketException with the error code 0x80004005 and the message “No such host is known”. This error explicitly indicates that the Test Agent machine is unable to translate the Test Controller’s hostname or FQDN into an IP address using the configured DNS resolution mechanisms.

I, 2013/02/08, 11:18:22.791, CreateControllerObject: attempt 0, System.Net.Sockets.SocketException (0x80004005): No such host is known

Server stack trace:
at System.Net.Dns.GetAddrInfo(String name)
at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
at System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket()
at System.Runtime.Remoting.Channels.RemoteConnection.GetSocket()
at System.Runtime.Remoting.Channels.SocketCache.GetSocket(String machinePortAndSid, Boolean openNew)
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.SendRequestWithRetry(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream)
at System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Microsoft.VisualStudio.TestTools.Controller.ControllerObject.Hello()
at Microsoft.VisualStudio.TestTools.ConfigCore.TestControllerHelper.CreateControllerObject(String controllerUri)
I, 2013/02/08, 11:18:22.918, CreateControllerObject: attempt 1, System.Net.Sockets.SocketException (0x80004005): No such host is known

This log excerpt highlights that the failure occurs during the initial attempt (Hello() method) to connect to the Controller Object, specifically within the DNS lookup process (System.Net.Dns.GetAddrInfo(String name)). Despite successful FQDN pings, the application-level hostname resolution is failing. This suggests an issue with how the operating system’s network stack or the application’s specific implementation performs DNS lookups across network boundaries.

Cause of the “No such host is known” Error

The core reason for this configuration failure, especially in cross-domain or workgroup setups, often boils down to hostname resolution inconsistencies. While you might be providing the fully qualified domain name (FQDN) for the Test Controller machine in the agent configuration tool (e.g., controller.contoso.com), the underlying communication layers or the application itself might attempt to resolve the hostname using mechanisms that fail when the machines are not in the same DNS domain or when DNS suffixes are not properly configured.

Specifically, this issue is frequently observed when the Test Agent and Test Controller machines cannot reliably communicate using only their machine hostnames (e.g., trying to resolve controller instead of controller.contoso.com). Even if pinging the FQDN works, the failure to resolve the shorter hostname or incomplete resolution paths for the FQDN across the network boundary without explicit DNS suffix guidance is the likely culprit. The operating system’s DNS client typically tries to resolve a hostname by first checking local caches, then the hosts file, and finally querying DNS servers. When only a hostname is provided, it appends the locally configured DNS suffixes to the hostname before querying DNS servers. If the required suffix to reach the other machine’s domain is not in the list of suffixes the client tries, the lookup fails. Conversely, even with an FQDN, if the DNS servers available to the agent machine cannot resolve names in the controller’s domain directly, or if the network setup requires appending suffixes for successful resolution across the boundary, the lookup can fail.

Resolution: Configuring DNS Suffixes

The most effective resolution involves configuring the TCP/IP settings on both the Test Agent and Test Controller machines to include the DNS suffix of the other machine’s domain. This ensures that when a hostname or FQDN lookup occurs, the operating system’s DNS client on each machine knows to append the necessary suffix to attempt resolution in the other domain or workgroup’s DNS namespace.

Troubleshooting Azure DevOps Test Agent Configuration Failures

Here are the detailed steps to configure the DNS suffixes on the Test Agent machine:

  1. Access Network Adapter Settings: Open the Network Connections window on the Test Agent machine. This can usually be done by right-clicking the network icon in the system tray or navigating through the Control Panel (Control Panel > Network and Internet > Network Connections).
  2. Open Adapter Properties: Right-click on the active Network Interface Card (NIC) or LAN connection being used for communication and select Properties.
  3. Access TCP/IP v4 Properties: In the properties dialog box for your network adapter, select Internet Protocol Version 4 (TCP/IP v4) from the list of protocols. Click the Properties button.
  4. Navigate to Advanced Settings: In the Internet Protocol Version 4 (TCP/IP v4) Properties dialog box, on the General tab, click the Advanced… button.
  5. Configure DNS Tab: In the Advanced TCP/IP Settings dialog box, switch to the DNS tab.
  6. Append DNS Suffixes: Under the “DNS suffix for this connection” section, select the radio button option Append these DNS suffixes (in order).
  7. Add Remote Domain Suffix: Click the Add… button. In the TCP/IP Domain Suffix dialog box, enter the DNS suffix for the Test Controller’s domain (e.g., contoso.com). Click Add.
  8. Confirm Changes: Click OK on the Advanced TCP/IP Settings dialog box.
  9. Confirm TCP/IP Properties: Click OK on the Internet Protocol Version 4 (TCP/IP v4) Properties dialog box.
  10. Close Adapter Properties: Click Close on the network adapter properties dialog box.

It is crucial to repeat these exact same steps on the Test Controller machine, but this time, append the DNS suffix of the Test Agent’s workgroup or domain (e.g., fabrikaam.com). This two-way configuration ensures that both machines can properly resolve hostnames across the network boundary using their configured DNS infrastructure supplemented by the appended suffixes.

Understanding the Communication Flow and Why Suffixes Help

Azure DevOps Test Controller and Test Agents often communicate using technologies like .NET Remoting or WCF. These technologies rely heavily on network naming and transport protocols. When establishing a connection using a URI like tcp://controller.contoso.com:6901/AgentService, the client (Test Agent) needs to resolve controller.contoso.com to an IP address.

The DNS client on the Test Agent machine performs this resolution. When it receives a name to look up, it follows a specific process:
1. Check local cache.
2. Check the hosts file.
3. If the name is a FQDN, it queries the configured DNS servers directly for that name.
4. If the name is a single label (hostname) or if the FQDN lookup fails and there are configured suffixes to append, it starts appending suffixes from its configured list (including the connection-specific suffix and the list configured in advanced settings) and queries DNS for each combination (e.g., controller.fabrikaam.com, then controller.contoso.com if contoso.com is added to the list).

In the scenario described, while the FQDN controller.contoso.com might be resolvable by ping if the agent’s DNS servers have correct forwarders or conditional forwarders configured for contoso.com, the application’s specific lookup or the underlying Remoting framework might behave differently, or the resolution path might be unreliable without explicit suffix configuration. By adding contoso.com to the “Append these DNS suffixes” list on the Test Agent machine, you are explicitly instructing the Test Agent’s operating system to try resolving names including those in the contoso.com domain, guiding the resolution process and increasing the chances of success. Similarly, adding fabrikaam.com to the Controller’s list helps with two-way communication or troubleshooting initiated from the controller side.

Verifying Connectivity and Name Resolution

Before and after applying the DNS suffix fix, it is essential to verify network connectivity and name resolution. Simple ping checks are useful but not sufficient.

Checking Hostname Resolution

Use command-line tools to explicitly check how names are resolved:

  • From Test Agent to Controller:

    • ping controller.contoso.com (Verifies FQDN pingability)
    • ping controller (Check if short name resolves - likely fails initially)
    • nslookup controller.contoso.com (Detailed DNS lookup for FQDN)
    • nslookup controller (Detailed DNS lookup for short name - observe which suffixes are tried)
    • Resolve-DnsName controller.contoso.com (PowerShell equivalent for FQDN)
    • Resolve-DnsName controller (PowerShell equivalent for short name)

  • From Test Controller to Agent:

    • ping agent.fabrikaam.com (Verifies FQDN pingability - assumes agent has an FQDN, or use its hostname if workgroup)
    • ping agent_hostname (Check short name resolution)
    • nslookup agent_hostname
    • Resolve-DnsName agent_hostname

After adding the DNS suffixes, re-run these commands. You should observe that pinging the short name (controller from the agent, agent_hostname from the controller) might now resolve correctly, or at least the nslookup/Resolve-DnsName output will show that the correct suffix is being appended during the lookup attempt.

Verifying Port Connectivity

The Test Agent and Controller communicate over specific ports. The default ports are 6901 for the Agent and 6900 for the Controller. These ports must be open in both directions between the machines.

  • From Test Agent to Test Controller (Port 6900):

    • telnet controller.contoso.com 6900 (Windows Telnet Client needs to be enabled)
    • Test-NetConnection controller.contoso.com -Port 6900 (PowerShell)

  • From Test Controller to Test Agent (Port 6901):

    • telnet agent_hostname 6901
    • Test-NetConnection agent_hostname -Port 6901

A successful Telnet or Test-NetConnection indicates that a network path exists and the firewall is not blocking the connection on that specific port. If these tests fail, investigate firewall rules (Windows Firewall on both machines and any intervening network firewalls) and routing.

Common Ports for Azure Test Agents/Controllers

Service Default Port Protocol Direction Purpose
Test Controller 6900 TCP Inbound (from Agent) Agent connects to Controller
Test Agent 6901 TCP Inbound (from Controller) Controller connects to Agent (for status, control etc.)

Ensure these ports are allowed in your network and operating system firewalls on both machines.

Additional Troubleshooting Steps

If configuring DNS suffixes doesn’t immediately resolve the issue, consider these additional steps:

  • Check hosts File: Examine the C:\Windows\System32\drivers\etc\hosts file on both machines. Ensure there are no incorrect or outdated manual mappings for the Test Controller or Test Agent hostnames that might be interfering with DNS resolution.
  • Verify Service Status: Ensure the Visual Studio Test Controller service is running on the controller machine and the Visual Studio Test Agent service is running on the agent machine. Restarting these services can sometimes help.
  • Review Test Controller URI Format: Double-check the URI entered in the Test Agent configuration tool. It should typically be in the format tcp://{ControllerName}:{Port}/AgentService. Using the FQDN (tcp://controller.contoso.com:6900/AgentService) is generally recommended, but the underlying resolution must work, which is what the DNS suffix fix facilitates. Ensure the port matches the one configured on the Test Controller.
  • Check Account Permissions: The account running the Test Agent service needs appropriate permissions to communicate with the Test Controller. While network connectivity is the primary focus of the “No such host is known” error, permission issues can manifest in later communication failures.
  • Network Configuration: Ensure the subnet masks, default gateways, and DNS server addresses are correctly configured on both machines.
  • Restart Network Adapters: Sometimes disabling and re-enabling the network adapter can refresh network settings, including DNS configuration.

Visualizing the Network Path (Mermaid Diagram)

Here is a simple diagram illustrating the network path and potential point of failure:

mermaid graph LR A[Test Agent fabrikaam.com] -- DNS Query: controller --> B(Agent's DNS Server) B -- Forward Query --> C(Controller's DNS Server) C -- Resolve: controller.contoso.com --> D[Test Controller contoso.com] D -- Return IP --> C C -- Return IP --> B B -- Return IP --> A A -- TCP Connection: IP:6900 --> D

The failure occurs in the path A --> B --> C --> D when A asks B to resolve controller (or controller.contoso.com if the suffix is missing or lookup fails without it), and the lookup process involving B and C cannot successfully return the IP address for the Test Controller’s name back to A. Adding the suffix contoso.com on A helps guide B (or A directly if B can query C) to look specifically for names ending in contoso.com.

Best Practices for Distributed Testing Environments

  • Consistent Naming: Use FQDNs consistently in configuration whenever possible.
  • Reliable DNS: Ensure robust and reliable DNS resolution between all machines involved in distributed testing. This includes correct forwarders, conditional forwarders, or stub zones if spanning multiple DNS namespaces.
  • Document Firewall Rules: Clearly document which ports are required and ensure network and host-based firewalls are configured correctly on all machines.
  • Test Connectivity Early: Before attempting configuration, always perform basic connectivity and name resolution tests (ping, nslookup/Resolve-DnsName, telnet/Test-NetConnection).
  • Use Dedicated Accounts: Run Test Controller and Agent services under specific domain accounts with necessary permissions, especially in domain environments.

While the No such host is known error specifically points to a name resolution problem, a solid understanding of the network topology, DNS configuration, and required communication ports is fundamental to successfully setting up and troubleshooting Azure DevOps Test Agents and Controllers in any environment, particularly those involving different network segments or administrative boundaries. Implementing the DNS suffix resolution is a targeted fix for a common root cause, but a holistic approach to network diagnostics is always recommended.

We hope this detailed guide helps you efficiently resolve test agent configuration failures. Encountering such errors can be frustrating, but a systematic approach to troubleshooting network fundamentals will lead you to the solution.

Do you have similar experiences or other tips for resolving this specific error? Share your thoughts and solutions in the comments below!

Post a Comment