AppSync: Discovery of Windows Hosts Fails with a Communication Error
요약: AppSync fails to discover the exchange host because the agent is unable to communicate with the Exchange server.
증상
In some cases, this may not cause any issues until the extra DNS name is edited or removed from DNS but not correctly updated on the target host. At this point, the agent will not longer be able to resolve the FQDN it is getting from getnameinfo to an IP address, and the discovery will fail.
Discovery of a Windows host and push install of the Agent files may fail. Attempts to ping the Host name, Fully Qualified Domain Name (FQDN), and IP of the host are successful. This may happen on an already discovered host or on a new install. During the push install, the Agent files will be pushed to the agent, but the Discovery phase of the install will fail.
You may see the following errors in the logs:
Server Logs:
<DATE> DEBUG [Thread-59 (HornetQ-client-global-threads-777292290)] [com.emc.archway.service.archwayagent.ArchwayConversation] [] [] c2fdae32-c9fe-44b3-9e5f-d60bf3c9f5e6->>> Connecting to host <FQDN of Windows Host> <DATE> ERROR [Thread-59 (HornetQ-client-global-threads-777292290)] [stderr] [] [] java.net.SocketException: Connection reset
Agent Logs:
<DATE> INFO [14032] [] [Host Name] [] setHostInfo:: hostname returned by getnameinfo is <Stale FQDN> <DATE> INFO [14032] [] [Host Name] [] m_hostname is <Stale FQDN> <DATE> INFO [14032] [] [Host Name] [] calling setAddrInfo for p_socket_instance hostname (Stale FQDN) <DATE> INFO [14032] [] [Host Name] [] setAddrInfo() called for host <Stale FQDN>
AppSync is detecting a DNS name for the Windows host that is no longer valid.
원인
This can occur when a host has more than one DNS entry in the DNS server. The AppSync agent uses the Windows getnameinfo function when running the Agent discovery to determine the name of the host. If the specific host has multiple DNS names, getnameinfo may not return the same name as the one entered in the AppSync GUI.
More details on "getnameInfo" can be found at the following link:
https://docs.microsoft.com/windows/win32/api/ws2tcpip/nf-ws2tcpip-getnameinfo
해결
-
The most appropriate solution is to work with a Network Administrator to ensure that the host returns the correct DNS name during discovery.
-
The command "nbtstat -n" can be used to show the DNS names registered on the host. This command will not show DNS names for Network adaptors that are not connected to the network.
-
The command "nbtstat -RR" can be used to force the host to update its DNS records from the DNS server.
-
If it is not possible to add the DNS entry back to the DNS server or to remove the record from the Agent, the issue can be worked around as follows. Update the hosts file on the target Windows host so that it resolves the FQDN to the IP address of the target host. The hosts file is located at C:\Windows\System32\Drivers\etc.