DBSS - Usability OS Connection alarm repeatedly firing while Windows agent connects normally (4371753)

DBSS - Usability OS Connection alarm repeatedly firing while Windows agent connects normally

DBSS - Usability OS Connection alarm repeatedly firing while Windows agent connects with no issues.

These alarms may be consistent, where the OS connection from the SQL Server agent on the FglAM (Foglight Agent Manager) cannot connect at all to the host, or there is an intermittent connection where sometimes it works and other times it does not.

A Windows agent however, configured to connect to the same Windows host using DCOM/WMI or WinRM can connect successfully.

This seems to be more prevalent after upgrading to releases at the 6.1.0 or higher.

The SQL Server agent handles reverse DNS resolution differently from the Windows agent in the 6.1.0 and higher releases. Usually these are

Hostname resolution or intermittent connection issues:

• network related (if both the WindowsAgent and SQL Server agent are affected)
• a hostname resolution issue on one of the two servers (clusters)
• multiple NICs (network interface cards) resolving host addresses ineffectively where one NIC doesn't have access to the subnet of the monitored host

Reviewing the hostname resolution

Review the Windows agent log file and look for a connection message similar to the following (the IP Addresses below are invalid and used for demonstration purposes only)

VERBOSE [FglAM:IncomingMessage[5]-1785] com.quest.remoteos.SystemMonitorImpl - Started data collection for host MYSERVER.MYDOMAIN.COM (also known as [MyServer.MyDomain.com  [MyServer.MyDomain.com (392.168.1.57)]]

Then review the database agent log file or alarms and look for a similar connection message to the (same) SQL Server host

>> Failure: Cannot establish connection to 451.168.2.26: A connection to the remote host 451.168.2.26 could not be established. Windows returned error code 0x800706ba [Caused by: ComFailException<="" p="">

[MYSERVER-lowPriorityPool-2-[DBSS_Host_Group][]] com.quest.glue.core.services.AgentEstablishedConnectionStore - Established a WinRMConnection connection to 451.168.2.26 [root/cimv2, NEGOTIATE, 5986]

In this example above the WindowsAgent and the SQL Server agents are both resolving the hostnames differently. The WindowsAgent is also being resolved to a FQDN while the SQL Server agent is using SQL Server computername without the FQDN, even it if might be added to the Agent Status Properties.

From a command line on the Foglight Agent Manager, do a NSLOOKUP using the

• FQDN of the monitored host (e.g. MYSERVER.MYDOMAIN.COM)
• servername of the monitored host (without the FQDN, e.g. MYSERVER)

The resulting results should be the same, with the "Address:" value under the resolved name being the same IP address for the FQDN (e.g. MYSERVER.MYDOMAIN.COM) and servername (e.g. MYSERVER).

Additionally, for a SQL Server cluster, also do a NSLOOKUP using the 

• clustername when monitoring a SQL Server cluster
• clustername with the FQDN of the SQL Server cluster

Here as well, the results should be the same, with the IP address for the FQDN of the clustername (e.g. MYCLUSTER.MYDOMAIN.COM) being the same as the IP address when only using the clustername (e.g. MYCLUSTER)

Correcting the DNS entries

If there are any differences between the IP addresses or if the hostname cannot be resolved, a short term workaround would be update the hosts file on the Foglight Agent Manager (FglAM) so that the hostname and FQDN both reference the correct IP address. This would likely be the one used by the working WindowsAgent.

for example, adding a line like this to the hosts file on the FglAM
392.168.1.57 myserver myserver.mydomain.com

A long term solution would be to update the DNS is include the correct IP addresses.