Troubleshooting DNS & Adding Another Domain to ControlUp

Summary

If your organization maintains several domains, you can monitor computers that reside in other domains from your main domain. No matter if you use 2-3 domains or dozens of domains. To maintain a successful connection from one AD to the other, some prerequisites are required.

In this troubleshooting article, we show you what it needs to connect ControlUp to multiple domains.

Prerequisites

1. The computer running the Real-Time Console should have LDAP access to the relevant AD forests’ Domain Controllers.
2. DNS conditional forwarding should be configured so the computer running the console is able to resolve any relevant AD DNS entries in the external forest.
3. The Console should have valid AD credentials in the external forest.
   • The credentials should be entered at the AD Connection section via the Settings menu.
4. The ControlUp Agent needs to be pre-installed on the relevant target computers (the agent MSI package can be used to accomplish this).
5. Ports \ Firewall -
   • TCP port 40705 (by default) must be opened on the external network to support console <–> agent communication.
   • For Hypervisor support, HTTPS port 443 has to be opened on the external network to support Console <-> Hypervisor communication. If you have a data collector in place, the port should be open from the data collector.

Possible Error message

If you add a domain and the connection is not successful, then the following error message is displayed:

ControlUp requires full DNS resolution for all managed computers.
If you are adding an Active Directory connection to an untrusted domain, you should verify that machines from that domain are accessible using their Fully Qualified Domain Names (FQDN).
If your DNS namespace for the untrusted domain is completely separate and inaccessible from your management machine, it is recommended that you configure a DNS conditional forwarders in order to enable DNS resolution.
For more information regarding DNS conditional forwarders, please refer to http://technet.microsoft.com/en-us/library/cc757172(v=ws.10).aspx");
}  

In this case, we need to check several aspects of the network to see where it fails.

Networking checks

• You can install a packet sniffer like Wireshark and analyze the communication and the DNS response that is being received.
  • An example of a failed DNS is shown below
    
• Validate that DNS-wise port 53 is available in TCP and UDP on the DNS server.
  • The DNS works mostly in UDP but DNS queries can also use TCP if UDP port 53 is not accepted.
• You can ping the remote AD but since it's another protocol (ICMP) it won't mean that LDAP is operational.
• Use LDP.exe from the Console machine to gain access with the same credentials you've set in the Console. LDP is a GUI tool that acts as an LDAP client so you can test the connection there.
• Check if there is some sort of a coalition between DNS configuration. E.g. if the Conditional Forwarder was configured correctly, maybe Forward Lookup Zone type secondary, hosts file on the AD? (just checking to validate).
• LDAP uses TCP port 389.
  • Some environments open TCP/389 only. Enable UDP/389 and re-check.
  • LDAP servers typically use the following ports:
    • TCP 3268 LDAP connection to Global Catalog
• 'nslookup' can also be useful to resolve the other AD by name / IP.

External articles on Conditional Forwarders

1. Configure a DNS Server to Use Forwarders (MS TechNet docs)
2. Using forwarders (MS TechNet docs)