What is this?

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

Learn more

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.

Free Download

Top Tags


View all Tags

Facing issues with the Windows Updates Status (PowerShell) sensor - can you help me?

Votes:

7

I use the Windows Updates Status (PowerShell) sensor to be up to date on available and installed Windows updates on my machines. However, the sensor is recently throwing errors when it used to work fine in the past. Can you explain why this happens and help me solve the issues?

cleanup error-messages powershell prtg update windows windows-update-sensor

Created on Oct 31, 2016 8:11:01 PM by Stephan Linke [Paessler Support]

Last change on Jan 4, 2023 2:44:24 PM by Brandy Greger [Paessler Support]



Best Answer

Accepted Answer

Votes:

0

This article applies as of PRTG 22

Important notice:

As of PRTG 21.x.66, the Windows Updates Status (PowerShell) sensor supports Negotiate authentication, with which you can use this sensor outside of domains. Find configuration instructions in section 2.2.

As of PRTG 18.4.47, the Windows Updates Status (PowerShell) sensor only shows the default channel Time since last update after creating the sensor. Other channels are created as needed when respective data arrives. If the sensor does not receive any other data, it does not create additional channels.

As of PRTG 17.4.36, the Windows Updates Status (PowerShell) sensor requires at least PowerShell 3.0, which must be installed on both the probe system and the target system. For more information, see Windows Updates Status (PowerShell) sensor: Detailed Requirements.

Potential issues with the Windows Updates Status (PowerShell) sensor and how to resolve them

You may encounter issues when you use the Windows Updates Status (PowerShell) sensor. This article lists the most common issues and how to resolve them.

1. Potentials issues and solutions

ProblemThe sensor shows a timeout error and PE018.
SolutionThere are two possible reasons for that - either the sensor simply could not connect to the target host or the PowerShell command probably takes too long to execute. Try to manually run the commands as shown above via a remote PowerShell session and see how long they take. If the command executes within the given time span of 20 minutes, run Windows Update and install all updates available for the system.

If the remote PowerShell session fails to connect, configure WinRM on the target host:
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/ff700227(v=msdn.10)

It might also be possible that the Windows Desktop Experience is installed on the server. If so, remove it because it will cause the update search to inevitably fail.
ProblemThe sensor shows a Kerberos authentication error and something about missing login servers.
SolutionIf the server you are checking is located in a workgroup, that is the problem because the sensor currently does not work with workgroups. There is currently nothing you can do about it. We are looking into this, but cannot promise anything. The sensor relies on Kerberos authentication, which is only available within a domain.
ProblemThe sensor shows an Exception from HRESULT: 0x80072EFD error.
SolutionThe error is rather ambiguous and can have multiple reasons. Either there is a problem with the internet connection of the target host or the sensor cannot connect to the WSUS server. Try to manually install updates to see if that solves the issue.
ProblemThe sensor shows an Exception from HRESULT: 0x8024402F error.
Solution1. Remove the contents of C:\ProgramData\Microsoft\Windows\Caches.
2. Rename Caches to Cache.
3. Start Windows Update. The error will occur again.
4. Rename Cache back to Caches and start Windows Update again.

The sensor should work properly now. Also, you need to manually install any available updates on the target host to rebuild the update database.
ProblemThe command basically works, but takes rather long.
SolutionAccording to one of our customers, it helps to clean out old updates in the WSUS to improve performance. This should increase the search speed as less updates are indexed.
ProblemThe sensor shows a PowerShell version not supported. Current PowerShell major version: 2. Please install PowerShell 3.0 or later error.
SolutionInstall PowerShell 3.0 or Windows Management Framework 3.0 or later on the target system that you want to monitor.
ProblemThe sensor shows a This sensor requires that PowerShell 2.0 or higher is installed on the probe system ( Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.Management.Automation, Version=3.0.0.0(...) (code: PE181) error.
SolutionThis error message is wrong and has been adjusted. Install PowerShell 3.0 or Windows Management Framework 3.0 or later on the probe system.

Issues on Windows 10, Windows Server 2016, or later

The following issues only occur on target systems that run Windows 10, Windows Server 2016, or later:

ProblemThe sensor shows a We could not identify a successful update in the last 10,000 history entries of Windows Update error.
SolutionPRTG searched 10,000 entries of the history and was not able to find a successfully installed update. Run Windows Update and try to manually install an update. Contact support for further assistance.
ProblemThe sensor shows an Update history does not contain any entries. Please enable the sensor debug options and contact support for further help error.
SolutionThis error occurred when there were some serious issues on the target device. Contact support for further assistance. Writing the sensor result to disk will be very helpful in solving the problem.

2. Additional topics

2.1 Functionality of the sensor

Here are the (simplified) steps that the sensor takes:

1. Use Windows credentials to open a remote PowerShell session to the target.

2. Execute the following command on the target host:
Note: For systems that run Windows versions as of Windows 10 or Windows Server 2016, a remote scheduled task executes this step. $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates This command basically gets all the updates available for this system.

Note: The sensor works in environments that use the normal update routine and in networks that have their own WSUS server.

2.1.1 Potential issues

While it may seem trivial, Windows updates can easily accumulate over time, resulting in hundreds of objects that have to be analyzed. The most crucial step is the second one. Depending on the amount of available updates and the bandwidth of the host (or the local WSUS), it can easily take minutes or even hours until the command is executed.

And that is the actual problem. If the sensor takes 20 minutes or more to execute the command, the child process is terminated. This is hard-coded and cannot be changed. You can discern if this is what happens to the Windows Update Status (PowerShell) sensor on your system by benchmarking the abovementioned command via Measure-Command: Measure-Command { $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates}

This command results in something like this (example values): 

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 43
Milliseconds      : 980
Ticks             : 9807034
TotalDays         : 1.13507337962963E-05
TotalHours        : 0.000272417611111111
TotalMinutes      : 0.439807034
TotalSeconds      : 43.9807034
TotalMilliseconds : 43.980.7034

This type of output is fine but your command execution time may vary depending on the actual updates you have installed.

2.2 How to use the Windows Updates Status (PowerShell) sensor with Negotiate authentication

In some scenarios, it is necessary to configure the probe system and the target system.

  • You must add a new trusted host on the probe system and update the firewall settings on the target system.

Add a new trusted host (for example, if you use Negotiate authentication with an IP address)

1. Open PowerShell with administrator privileges on the probe system.

2. Run the following commands:

  • Get a list of trusted hosts:

Get-Item WSMan:\localhost\Client\TrustedHosts

  • Add a new trusted host:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>,[<ComputerName>]

  • Patch the trusted hosts:

Set-Item WSMan:\localhost\Client\TrustedHosts -Concatenate -Value Server02

Update the firewall settings on the target system (for example, if you use Negotiate authentication with workgroups or across domains without trust)

  1. Open PowerShell with administrator privileges on the target system.
  2. Run the following command to update the firewall rules: Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress <ip address of the probe>

More

Created on Aug 31, 2017 1:03:54 PM by Martina Wittmann [Paessler Support]

Last change on Apr 10, 2024 1:29:14 PM by Jacqueline Conforti [Paessler Support]



30 Replies

Votes:

0

Hi Paessler Support, I keep getting Error PE018 on SOME of my Windows Update (Powershell) Sensors. When I run this script:

Invoke-Command -ComputerName XXX -ScriptBlock { Measure-Command { $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates | Sort-Object -Property Dates -Descending | ft -autosize IsInstalled, MsrcSeverity } }

from my PRTG Server, I get a result of just a minute runtime for the script.

What can I check next?

Created on Aug 30, 2017 12:04:06 PM



Votes:

0

Hi Bernd,

Most recent PRTG version (17.3.33.2686) already installed?

Kind regards,
Stephan Linke, Tech Support Team

Created on Aug 30, 2017 8:41:51 PM by Stephan Linke [Paessler Support]



Accepted Answer

Votes:

0

This article applies as of PRTG 22

Important notice:

As of PRTG 21.x.66, the Windows Updates Status (PowerShell) sensor supports Negotiate authentication, with which you can use this sensor outside of domains. Find configuration instructions in section 2.2.

As of PRTG 18.4.47, the Windows Updates Status (PowerShell) sensor only shows the default channel Time since last update after creating the sensor. Other channels are created as needed when respective data arrives. If the sensor does not receive any other data, it does not create additional channels.

As of PRTG 17.4.36, the Windows Updates Status (PowerShell) sensor requires at least PowerShell 3.0, which must be installed on both the probe system and the target system. For more information, see Windows Updates Status (PowerShell) sensor: Detailed Requirements.

Potential issues with the Windows Updates Status (PowerShell) sensor and how to resolve them

You may encounter issues when you use the Windows Updates Status (PowerShell) sensor. This article lists the most common issues and how to resolve them.

1. Potentials issues and solutions

ProblemThe sensor shows a timeout error and PE018.
SolutionThere are two possible reasons for that - either the sensor simply could not connect to the target host or the PowerShell command probably takes too long to execute. Try to manually run the commands as shown above via a remote PowerShell session and see how long they take. If the command executes within the given time span of 20 minutes, run Windows Update and install all updates available for the system.

If the remote PowerShell session fails to connect, configure WinRM on the target host:
https://docs.microsoft.com/en-us/previous-versions/technet-magazine/ff700227(v=msdn.10)

It might also be possible that the Windows Desktop Experience is installed on the server. If so, remove it because it will cause the update search to inevitably fail.
ProblemThe sensor shows a Kerberos authentication error and something about missing login servers.
SolutionIf the server you are checking is located in a workgroup, that is the problem because the sensor currently does not work with workgroups. There is currently nothing you can do about it. We are looking into this, but cannot promise anything. The sensor relies on Kerberos authentication, which is only available within a domain.
ProblemThe sensor shows an Exception from HRESULT: 0x80072EFD error.
SolutionThe error is rather ambiguous and can have multiple reasons. Either there is a problem with the internet connection of the target host or the sensor cannot connect to the WSUS server. Try to manually install updates to see if that solves the issue.
ProblemThe sensor shows an Exception from HRESULT: 0x8024402F error.
Solution1. Remove the contents of C:\ProgramData\Microsoft\Windows\Caches.
2. Rename Caches to Cache.
3. Start Windows Update. The error will occur again.
4. Rename Cache back to Caches and start Windows Update again.

The sensor should work properly now. Also, you need to manually install any available updates on the target host to rebuild the update database.
ProblemThe command basically works, but takes rather long.
SolutionAccording to one of our customers, it helps to clean out old updates in the WSUS to improve performance. This should increase the search speed as less updates are indexed.
ProblemThe sensor shows a PowerShell version not supported. Current PowerShell major version: 2. Please install PowerShell 3.0 or later error.
SolutionInstall PowerShell 3.0 or Windows Management Framework 3.0 or later on the target system that you want to monitor.
ProblemThe sensor shows a This sensor requires that PowerShell 2.0 or higher is installed on the probe system ( Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.Management.Automation, Version=3.0.0.0(...) (code: PE181) error.
SolutionThis error message is wrong and has been adjusted. Install PowerShell 3.0 or Windows Management Framework 3.0 or later on the probe system.

Issues on Windows 10, Windows Server 2016, or later

The following issues only occur on target systems that run Windows 10, Windows Server 2016, or later:

ProblemThe sensor shows a We could not identify a successful update in the last 10,000 history entries of Windows Update error.
SolutionPRTG searched 10,000 entries of the history and was not able to find a successfully installed update. Run Windows Update and try to manually install an update. Contact support for further assistance.
ProblemThe sensor shows an Update history does not contain any entries. Please enable the sensor debug options and contact support for further help error.
SolutionThis error occurred when there were some serious issues on the target device. Contact support for further assistance. Writing the sensor result to disk will be very helpful in solving the problem.

2. Additional topics

2.1 Functionality of the sensor

Here are the (simplified) steps that the sensor takes:

1. Use Windows credentials to open a remote PowerShell session to the target.

2. Execute the following command on the target host:
Note: For systems that run Windows versions as of Windows 10 or Windows Server 2016, a remote scheduled task executes this step. $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates This command basically gets all the updates available for this system.

Note: The sensor works in environments that use the normal update routine and in networks that have their own WSUS server.

2.1.1 Potential issues

While it may seem trivial, Windows updates can easily accumulate over time, resulting in hundreds of objects that have to be analyzed. The most crucial step is the second one. Depending on the amount of available updates and the bandwidth of the host (or the local WSUS), it can easily take minutes or even hours until the command is executed.

And that is the actual problem. If the sensor takes 20 minutes or more to execute the command, the child process is terminated. This is hard-coded and cannot be changed. You can discern if this is what happens to the Windows Update Status (PowerShell) sensor on your system by benchmarking the abovementioned command via Measure-Command: Measure-Command { $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates}

This command results in something like this (example values): 

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 43
Milliseconds      : 980
Ticks             : 9807034
TotalDays         : 1.13507337962963E-05
TotalHours        : 0.000272417611111111
TotalMinutes      : 0.439807034
TotalSeconds      : 43.9807034
TotalMilliseconds : 43.980.7034

This type of output is fine but your command execution time may vary depending on the actual updates you have installed.

2.2 How to use the Windows Updates Status (PowerShell) sensor with Negotiate authentication

In some scenarios, it is necessary to configure the probe system and the target system.

  • You must add a new trusted host on the probe system and update the firewall settings on the target system.

Add a new trusted host (for example, if you use Negotiate authentication with an IP address)

1. Open PowerShell with administrator privileges on the probe system.

2. Run the following commands:

  • Get a list of trusted hosts:

Get-Item WSMan:\localhost\Client\TrustedHosts

  • Add a new trusted host:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value <ComputerName>,[<ComputerName>]

  • Patch the trusted hosts:

Set-Item WSMan:\localhost\Client\TrustedHosts -Concatenate -Value Server02

Update the firewall settings on the target system (for example, if you use Negotiate authentication with workgroups or across domains without trust)

  1. Open PowerShell with administrator privileges on the target system.
  2. Run the following command to update the firewall rules: Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress <ip address of the probe>

More

Created on Aug 31, 2017 1:03:54 PM by Martina Wittmann [Paessler Support]

Last change on Apr 10, 2024 1:29:14 PM by Jacqueline Conforti [Paessler Support]



Votes:

0

Support -

I have two probes, one local & one remote, running Windows 2008 R2 and each has the Windows Update Status Sensor installed. Both were working fine with v17.1.28.1032. Yesterday I installed v17.3.33.2753 and when the Servers rebooted each Sensor reported a PE018 Timeout error. I deleted both Sensors and re-added them and still have the same PE018 error. I ran the Measure-Command above on the local probe and it reports 28 seconds.

Is there something I need to change because of the upgrade to v17.3.33.2753?

Created on Sep 7, 2017 1:24:47 AM



Votes:

0

Hello MCQ,

There are currently a few issues with the Windows Update Status sensor in this version, a hotfix release should be coming out soon after internal testing has been finished.

Kind regards,

Erhard

Created on Sep 7, 2017 8:34:28 AM by Erhard Mikulik [Paessler Support]



Votes:

0

We get a 'No result returned from remote host' with 'Windows Updates Status' on a server which previously could be monitored just fine. We rebooted the server, error remains. All other sensors work just fine.

What could be the cause of this?

Created on Apr 23, 2018 7:41:32 AM



Votes:

0

bvanhaastrecht, to allow us a better overview of what is going with this Windows Update Sensor on, please send us the following screenshots of the affected sensor (out of the PRTG AJAX Webinterface):
- the "Overview" tab,
- the "Log" tab,
- the "Settings" tab (multiple screenshots if necessary to cover all options).

Please make sure the screenshots show the entire user interface, and aren't cropped.

To debug this, we would like to look into the sensor debug log for the sensor. To activate this debug log, please enable the "Write Result to Disk" Option in the settings of the sensor. And then forward us the logfile. You will find it in the "Logs (Sensors)"-Subfolder of the data directory of the according PRTG Probe running this sensor.

Please send everything with an email to [email protected] with a reference to this KB-Post.

Created on Apr 23, 2018 12:54:36 PM by Torsten Lindner [Paessler Support]

Last change on Apr 23, 2018 12:55:03 PM by Torsten Lindner [Paessler Support]



Votes:

1

I have missed this reply. Thank you, and i've send support the requested information. PAEXXXX597

Created on May 2, 2018 12:00:41 PM

Last change on May 3, 2018 10:43:14 AM by Luciano Lingnau [Paessler]



Votes:

0

I have a bunch of Server 2016 machines, which I point to a WSUS server not hosting updates for the OS to cirumvent nasty unwanted reboots, which happened in the past on those systems. These are updated manually each month via online updates, so they should not cause PRTG to raise the error flag, which they seem to do according to the last item in the list. Is there a way around this?

Best greetings from Germany Olaf

Created on Jun 13, 2018 9:12:13 PM



Votes:

0

Olaf, may I ask, which exact error do those particular sensors then show? Can you share a screenshot showing it please?

Created on Jun 14, 2018 8:24:14 AM by Torsten Lindner [Paessler Support]



Votes:

0

I do not think, that I can share a screenshot displaying a customers machine status hosted on a 3rd party website. But the text shown is not that hard to type: Sensor: Windows Update Status Probe device: XXX Status: Error Message: The target machine YYY did not report any updates.

Best greetings from Germany Olaf

Created on Jun 27, 2018 11:59:11 AM



Votes:

0

It looks though, as if this isn't really a sensor error to be honest, but the target simply reporting no updates. To confirm this, we would like to look into the sensor debug log for the sensor. To activate this debug log, please enable the "Write Result to Disk" Option in the settings of the sensor. And then forward us the logfile. You will find it in the "Logs (Sensors)"-Subfolder of the data directory of the according PRTG Probe running this sensor (https://kb.paessler.com/en/topic/463-how-and-where-does-prtg-store-its-data). You can send us the debug log via email in responds to this KB-Thread.

Created on Jun 27, 2018 2:11:32 PM by Torsten Lindner [Paessler Support]



Votes:

0

Sorry, kept busy enough to see this answer just now. Thanks for the reply. Since this is a customer system, I cannot send the logs currently.

I go with you, that this is not necessarly a sensor error: The answer to "The sensor errors with The target machine HOST did not report any updates.?" explains, that this is intended.

But why make this the reason for error status? There was this other depreciated sensor https://blog.paessler.com/prtg-windows-last-update-sensor This in combination with the newer one could help to determine, if the system is in a critical stage update wise or not. (If the last updates have been installed within the last xx days PRTG could assume the system is not a forgotten one.

It might also help not to rely solely on WSUS since there is no warranty, that all required updates are approved on the WSUS server.

Created on Jul 10, 2018 10:19:06 AM



Votes:

0

I do understand the point. Nevertheless, with the reality that hardly any up-to-date windows machines have no updates installed, we see it reasonably to have this as an error.

Created on Jul 10, 2018 1:24:01 PM by Torsten Lindner [Paessler Support]



Votes:

0

The link for the PwrShell 2.0 sensor is broken. http://download3.paessler.com/support/LastWindowsUpdateSensor_17.4.35.zip

Created on Aug 3, 2018 9:55:56 AM



Votes:

0

Hi Ringo,

Thanks for the hint, it's fixed now and should be available in a few minutes :)

Kind regards,
Stephan Linke, Tech Support Team

Created on Aug 3, 2018 12:56:27 PM by Stephan Linke [Paessler Support]



Votes:

0

Hello,

i have a few Windows2016 Server which wont report any Updates: "The target machine XXX did not report any updates."

If i get on Powershell and run: $searcher = (New-Object -ComObject Microsoft.Update.Session).CreateUpdateSearcher();$searcher.Search("Type='Software'").Updates $searcher | Select-Object -Property * I get:

CanAutomaticallyUpgradeService      : False
ClientApplicationID                 : 
IncludePotentiallySupersededUpdates : False
ServerSelection                     : 0
Online                              : True
ServiceID                           : 00000000-0000-0000-0000-000000000000
IgnoreDownloadPriority              : False
SearchScope                         : 0

On older Servers like 2012 i get all the information and the Sensor is up.

It looks like that Servers who directly connect to a WSUS Server are working. But we have also Microsoft SystemCenter with a second WSUS in use, all new Servers are controlled by the SystemCenter. Those arent working.

Any ideas?

Kind regards, Sebastian

Created on Sep 18, 2018 9:09:25 AM



Votes:

0

Hi Sebastian,

In this case, we can't properly discern if there are indeed no updates or if we didn't get any information from the host. In this case, please acknowledge the error for the time being. It will go green again once new updates are installed.

Kind regards,
Stephan Linke, Tech Support Team

Created on Sep 18, 2018 9:22:20 AM by Stephan Linke [Paessler Support]

Last change on Sep 18, 2018 9:22:25 AM by Stephan Linke [Paessler Support]



Votes:

0

link is dead again can you update it please http://download3.paessler.com/support/LastWindowsUpdateSensor_17.4.35.zip

Created on Mar 25, 2019 10:51:52 AM



Votes:

0

What exact issues are you encountering with the Sensor?

More

Kind regards,
Stephan Linke, Tech Support Team

Created on Mar 25, 2019 3:11:29 PM by Stephan Linke [Paessler Support]

Last change on Jul 5, 2019 8:18:07 AM by Maike Guba [Paessler Support] (2,404) ●2 ●1



Votes:

0

i get this error on one of my servers, i did powerschell remote session from the probe device to the target server (that one with this error) and ran the windows update sensor script perfect in 4-5 min (Connecting to remote server ** failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.)

Created on Mar 25, 2019 3:37:42 PM



Votes:

0

This is most likely something with WinRM being unable to connect. The old version won't do the trick here either. Is this a host within the same domain? FQDN used for the device address?

More

Kind regards,
Stephan Linke, Tech Support Team

Created on Mar 26, 2019 1:52:49 PM by Stephan Linke [Paessler Support]

Last change on Jul 5, 2019 8:17:52 AM by Maike Guba [Paessler Support] (2,404) ●2 ●1



Votes:

0

I receive no error, but this sensor only report "Elapsed time since the last windows update" (translated) for each Windows Server 2016 machine. There is no WSUS roles on any of those servers. A windows 10 virtual machine report this channel and several others for different type of updates.

WinRM works for each of them as I use "Windows Admin Center" from my personal PC and access Windows Update functions with success on each of them and this function of WAC uses powershell and WinRM. Framework 4.8 (who includes 4.7) as been installed on the probe server. The goal is to have all the channels for each Windows Server machine.

WAC provides the powershell scripts they use. Here is what they use concerning Windows Updates : https://medium.com/@RealNetwork/the-windows-admin-center-1809-powershell-scripts-f2923c70fb8f

Created on May 2, 2019 10:18:03 AM

Last change on May 2, 2019 10:31:49 AM by Stephan Linke [Paessler Support]



Votes:

0

I took the freedom to remove the actual script for the sake of readability, thanks for sharing that one! Much appreciated. The issue is known to us and we're working on a fix; however, it will likely take some time as the way we transport results between target host and PRTG is what's causing the issue (the base64 object is getting too large).

I hope that this will be fixed eventually in a future PRTG version :)

More

Kind regards,
Stephan Linke, Tech Support Team

Created on May 2, 2019 10:34:39 AM by Stephan Linke [Paessler Support]

Last change on Jul 5, 2019 8:17:44 AM by Maike Guba [Paessler Support] (2,404) ●2 ●1



Votes:

2

Regarding the error: "WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred"... I just ran into that myself.

In my case, the issue stemmed from the server/device being queried already having a SPN created for HTTP/myserver.mydomain.com, which an application on the machine was using. That SPN was tied to a specific service account which causes WinRM to not work when invoked over Kerberos since from a Kerberos perspective the WinRM service runs under the domain machine account. Google for "winrm kerberos existing SPN" and you'll see a variety of hits on this topic.

Ultimately it would be nice if the PRTG Windows Update Sensor app (LastWindowsUpdateSensor.exe) was able to/had an option to query for the SPN and include the port number. That's an option when invoking WinRM over PowerShell directly (-EncodePortInServicePrincipalName) that would cause it to query for HTTP/myserver.mydomain.com:<win rm port> which would not conflict with any existing SPNs.

I did find a possible workaround. On the PRTG sensor server, I was able to add a string registry value under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Client\spn_prefix = "WSMAN". That seems to force PRTG to use the SPN WSMAN/myserver.mydomain.com instead of HTTP/myserver.mydomain.com. I could not find any documentation on the spn_prefix value. I saw that while watching the PRTG Windows Update sensor execute with MS Process Monitor.

Ultimately whatever SPN is being requested from the PRTG sensor (you can watch network traffic with Wireshark on the PRTG sensor server and see the SPN service name) must tie back to the domain machine account in order for Kerberos credentials to transmit correctly.

Created on May 3, 2019 12:05:31 AM



Votes:

0

Thanks! I've updated our solution guide with a link to your post :)

More

Kind regards,
Stephan Linke, Tech Support Team

Created on May 3, 2019 7:45:46 AM by Stephan Linke [Paessler Support]

Last change on Jul 5, 2019 8:17:31 AM by Maike Guba [Paessler Support] (2,404) ●2 ●1



Votes:

0

Hi, the link for 2.0 version isnt working, could you update it?

http://download3.paessler.com/support/LastWindowsUpdateSensor_17.4.35.zip

Created on May 21, 2019 10:42:01 AM



Votes:

0

What exact issue are you running into and what version of PRTG are you running?

Created on May 21, 2019 12:49:34 PM by Stephan Linke [Paessler Support]



Votes:

0

Hey, following problem: Probe is AD-Joined and the server we want to monitor windows updates is standalone Workgroup. I´ve already set the FQDN as trused host and getting the list back: Get-Item WSMan:\localhost\Client\TrustedHosts

Since i´ve done this, PS-Remoting is working fine from probe to standalone server. But if i use following command to test the sensor or script: S C:\Program Files (x86)\PRTG Network Monitor\Sensor System> .\LastWindowsUpdateSensor.exe -host='HOSTNAME' -user='HOSTNAME\Administrator' -pass='localadminpassword'

i´ll get following Error Message back: <prtg> <error>1</error> <text>Connecting to remote server SRBBACK01.bgz.glasmarte.at failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domains and there is no trust between the two domains. After checking for the above issues, try the following: -Check the Event Viewer for events related to authentication. -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport. Note that computers in the TrustedHosts list might not be authenticated. -For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.</text>

I´ve already done the PSRemoting, PS Execution Policy and either Windows Firewall but nothing helped. Thanks for the help!

Created on Aug 28, 2019 8:45:20 AM

Last change on Aug 28, 2019 8:45:20 AM



Votes:

0

Please check out this one to see if any of the proposed approaches under Conclusion helps.

Created on Aug 28, 2019 12:42:37 PM by Stephan Linke [Paessler Support]




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.