What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Windows Update Status "No such host is known"

Votes:

0

Hi,

a Windows Update Status Sensor reports "Last Message" as "No such host is known". Is the Message "No such host is known" delivered by the target device where i want to know the update Status from? Or does this mean, that the prtg cannot find the host?

Other Sensors on this device work fine.

The file "Result of Sensor [ID].txt" Looks like:

<?xml version="1.0" encoding="utf-8"?>
<prtg>
  <error>1</error>
  <text>No such host is known</text>
</prtg>

in the file "Result of Sensor [ID].Data.txt", the following part looks OK

Data['environment'].asString := '';
Data['exefile'].asString := 'LastWindowsUpdateSensor.exe';
Data['exeparams'].asString := ' -host="10.xx.xx.xx" -timeout=43198 -port=5985 -user="xxxxxx.xxxxx\serviceprtg" -pass="***" "-debugfile=C:\ProgramData\Paessler\PRTG Network Monitor\Logs (Sensors)\Result of Sensor [ID].log"';
Data['fastcount'].asString := '0';
Data['host'].asString := '10.xx.xx.xx';

best regards

D.

last-sensor-state prtg windows-update-status

Created on Apr 19, 2017 9:29:38 AM

Last change on Jun 27, 2018 5:17:23 AM by Luciano Lingnau [Paessler]

Best Answer

Accepted Answer

Votes:

5

Hi All,

I had this same issue. Multiple devices in the same IP subnet as my local probe all working fine (non-PowerShell sensors and PowerShell sensors). But two devices in a different IP subnet with all 'normal' sensors were working just fine, but the PowerShell sensor for Windows Updates failing. It was reporting 'No such host is known'.

After some digging around I could validated the following:

TCP 5985 wasn't blocked (used telnet from the monitoring probe host)
Remote PowerShell was working (from the probe server:

 Invoke-Command -ComputerName <hostname> -ScriptBlock {hostname}

I then tried the above Invoke-Command again, but with just the IP address as I noticed in the logs above and in my logs the IP address was used by the sensor. This failed with the below error message:

[aaa.bbb.yyy.zzz] Connecting to remote server aaa.bbb.yyy.zzz failed with the following error message : The WinRM client
cannot process the request. Default authentication may be used with an IP address under the following conditions: the
transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use
winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more
information on how to set TrustedHosts run the following command: winrm help config. For more information, see the
about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (aaa.bbb.yyy.zzz:String) [], PSRemotingTransportException
    + FullyQualifiedErrorId : CannotUseIPAddress,PSSessionStateBroken

This led me down to figuring out why the Invoke-Command failed with an IP address, but not with a host name. In my case I did not try to fix the issue with altering the trusted host list or behavior, because the sensors on same subnet worked just fine by IP address. So I kept digging. I was able to dig out the actual PowerShell command in the 'Windows Update Status' sensor and tried that with both IP address and hostname:

> & 'C:\Program Files (x86)\PRTG Network Monitor\Sensor System\LastWindowsUpdateSensor.exe' -host="<IP_Address>" -user="<username>" -pass="<password>"

> & 'C:\Program Files (x86)\PRTG Network Monitor\Sensor System\LastWindowsUpdateSensor.exe' -host="<Hostname>" -user="<username>" -pass="<password>"

The IP address command failed with 'No such host is known', but the same command with the hostname succeeded! I then looked into the device itself and realized I had created all devices based on IP address. I changed the two device with the failing sensor to FQDNs and now it works perfectly. I don't know why exactly an IP address invoked across a subnet causes this behavior but changing it to hostname fixed my issue.

Hope this helps!

Tyson

Created on Oct 16, 2017 4:03:43 PM

Last change on Oct 17, 2017 5:54:21 AM by Sven Roggenhofer [Paessler Technical Support]

13 Replies

Votes:

0

Dear DieterD

The message indicates that the sensor is unable to connect to the address provided via the -host parameter. Please check from the command line, run on the probe, if you can ping said host address. As an alternative, please try the Windows Update Status sensor.

Created on Apr 20, 2017 12:50:55 PM by Arne Seifert [Paessler Support]

Votes:

0

I'm having the same issue and I can't find anything online about how to fix it. I have the sensor working fine on 20+ other hosts and every other sensor works fine on these 3 hosts with the "No such host is known" message. Ping, dns all work fine from monitor server to sensor client. We are running an older version at 16.2.23.3234+ but aren't in a licensing state to upgrade at this time. I'm not sure what else to check?

Created on Sep 22, 2017 10:05:36 PM

Votes:

0

Hey Brian,

Please open a new support case for this issue (using the ticket number PAE929490) and forward us screenshots and result files from the affected sensor.

Thank you very much in advance. Sven

Created on Sep 25, 2017 11:41:08 AM by Sven Roggenhofer [Paessler Technical Support]

Accepted Answer

Votes:

5

Hi All,

I had this same issue. Multiple devices in the same IP subnet as my local probe all working fine (non-PowerShell sensors and PowerShell sensors). But two devices in a different IP subnet with all 'normal' sensors were working just fine, but the PowerShell sensor for Windows Updates failing. It was reporting 'No such host is known'.

After some digging around I could validated the following:

TCP 5985 wasn't blocked (used telnet from the monitoring probe host)
Remote PowerShell was working (from the probe server:

 Invoke-Command -ComputerName <hostname> -ScriptBlock {hostname}

I then tried the above Invoke-Command again, but with just the IP address as I noticed in the logs above and in my logs the IP address was used by the sensor. This failed with the below error message:

[aaa.bbb.yyy.zzz] Connecting to remote server aaa.bbb.yyy.zzz failed with the following error message : The WinRM client
cannot process the request. Default authentication may be used with an IP address under the following conditions: the
transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use
winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more
information on how to set TrustedHosts run the following command: winrm help config. For more information, see the
about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (aaa.bbb.yyy.zzz:String) [], PSRemotingTransportException
    + FullyQualifiedErrorId : CannotUseIPAddress,PSSessionStateBroken

This led me down to figuring out why the Invoke-Command failed with an IP address, but not with a host name. In my case I did not try to fix the issue with altering the trusted host list or behavior, because the sensors on same subnet worked just fine by IP address. So I kept digging. I was able to dig out the actual PowerShell command in the 'Windows Update Status' sensor and tried that with both IP address and hostname:

> & 'C:\Program Files (x86)\PRTG Network Monitor\Sensor System\LastWindowsUpdateSensor.exe' -host="<IP_Address>" -user="<username>" -pass="<password>"

> & 'C:\Program Files (x86)\PRTG Network Monitor\Sensor System\LastWindowsUpdateSensor.exe' -host="<Hostname>" -user="<username>" -pass="<password>"

The IP address command failed with 'No such host is known', but the same command with the hostname succeeded! I then looked into the device itself and realized I had created all devices based on IP address. I changed the two device with the failing sensor to FQDNs and now it works perfectly. I don't know why exactly an IP address invoked across a subnet causes this behavior but changing it to hostname fixed my issue.

Hope this helps!

Tyson

Created on Oct 16, 2017 4:03:43 PM

Last change on Oct 17, 2017 5:54:21 AM by Sven Roggenhofer [Paessler Technical Support]

Votes:

0

Hey Tyson,

Thank you very much for sharing this information. We really appreciate it.

Best regards,
Sven

Created on Oct 17, 2017 5:56:39 AM by Sven Roggenhofer [Paessler Technical Support]

Votes:

0

Hello Paessler support,

I have the same problem, but my servers are inside a DMZ and not part of any Domain and thus not in DNS. I'm sure PRTG know their hostnames and/or can check the local hostname before issuing a command.

What do I have to do?

Created on Nov 9, 2017 10:14:52 AM

Last change on Nov 9, 2017 12:17:35 PM by Stephan Linke [Paessler Support]

Votes:

0

Hey soomon,

in that case we recommend to install a Remote Probe on one of the target servers. This should solve the issue.

Best regards,
Sven

Created on Nov 9, 2017 12:20:33 PM by Sven Roggenhofer [Paessler Technical Support]

Votes:

0

So instead of fixing the sensor for everyone by adding something like [System.Net.Dns]::GetHostByName(($env:computerName)) the suggested solution is to install more probes?

Created on Nov 13, 2017 2:00:16 PM

Votes:

0

Hey soomon,

As you mentioned in your previous post, DNS is not working in this scenario, so how could PRTG know the hostnames if DNS is not working?

Log on to the PRTG probe host where the target hosts from the DMZ are currently located and try to run a nslookup in the CMD. Does it work? If so, PRTG should be able to resolve the hostnames as well.

Best regards,
Sven

Created on Nov 14, 2017 5:47:13 AM by Sven Roggenhofer [Paessler Technical Support]

Votes:

0

Any Update on this? Facing currently the same Issue.

Created on Jun 26, 2018 2:42:25 PM

Votes:

0

Hey Jens,

which precise steps have you taken and what was the outcome?

Best regards,
Sven

Created on Jun 27, 2018 5:19:37 AM by Sven Roggenhofer [Paessler Technical Support]

Votes:

1

Hello!

Today I have experienced the same problem ... and I found a solution :)

At 2 of ca. 40 server this problem occured. When checking the DNS I found the problem/solution.

The A record in the Forward Lookup Zone was correct, but there was no Pointer record in the Reverse Lookup Zone (because the zone for this subnet was just missing). So, adding the Reverse Lookup Zone, run an "ipconfig /registerdns" in an administrative shell on those two servers ... waiting a few minutes ... and now it is working correctly.

Best regards

Tobias

Created on Nov 29, 2018 1:17:30 PM

Votes:

0

Had the kind of the same issue as mestert. PTR-record was present but pointing to "wrong" dns-name. After removing the PTR record and running ipconfig /registerdns the sensor started reporting again.

Host was added by IP so was a bit confused by the error message which was reporting the wrong FQDN that was resolved by the incorrect PTR.

Created on Oct 7, 2021 7:57:50 AM

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.